How can I avoid preemption of my thread in user mode

Question

I have a simple chunk of deterministic work that only takes thirteen machine instructions to complete. Because the first instruction takes a homemade semaphore (spinlock) and the last instruction releases it, I am safe from all of the other threads running on the other cores as they are attempting to take and give the same semaphore.

The problem arises when some thread interrupts a thread holding the semaphore before it can finish its "critical section". Worst case the interruption kills the thread while holding the semaphore or as can happen one of the threads normally competing for the semaphore branches out into code that can generate the interrupt causing a deadlock.

I don't have a way synchronizing with these other threads when they branch into those parts of the code I can't control. I think I need to disable interrupts like I used to do in my old VxWorks days when I was running in kernel mode. Its always thirteen instructions and I am always completely safe if I can get all thirteen instructions done before I have to honor an interrupt. Oh and it is all my own internal data, other that the homemade semaphore there is nothing that locks anything else up.

I have read several answers that I think are close. Most have to do with Critical Section calls on the Windows API (wrong OS but maybe the right concept). Most of the wrong solutions assume that I can get all of the offending threads to use a mutex that I create with the pthread libraries.

I need this solution in C/C++ on Linux and Solaris.

Johnny Crash's question is very close prevent linux thread from being interrupted by scheduler

KermitG also Can I prevent a Linux user space pthread yielding in critical code?

Thanks for your consideration.

Answer 1

Yes, yes - 7 years old - I need to do exactly this but for other reasons. So I put this here for others to read in a historical context.

I am writing an emulation layer for an embedded RTOS where I need to emulate the embedded platform CPU_irq_disable(), and CPU_irq_restore() The closest thing I can think of is to disable peemption in the scheduler.

Yes, the target does have an RTOS - sometimes it does not.

IO is emulated via sockets, ie: a serial port is like a stream socket!

A GPIO pin (Edge IRQ) can be a socket to. The current value is in a quasi-global to the driver, and to wait for a pin change = waiting for a packet to arrive on a socket.

So the socket read thread acts like an IRQ when a packet shows up. Thus- to emulate irq disable, it is reasonable to emulate by disabling pre-emption within my own application.

Also at the embedded application layer, I need to emulate what would be a superloop.

No amount of mutex stuff is going to emulate the embedded platform reasonably.

Answer 2

You may not prevent preemption of a user-mode thread. Critical sections (and all other sync objects) prevent collisions of your threads, however they by no means prevent them from preemption by the OS.

If your other threads branch into something on timeout, whereas that something may lead to a deadlock - you have a design problem.

A correct design should be the most pessimistic: preemption may occur everywhere for indeterminate time.