Hello, I'm currently working on a project that is working on porting an application from VxWorks to user space on Linux, with the preempt_rt patch. One big item VxWorks specific feature that we used a lot is an "intLock()" as a form of a critical section, to lock out all other scheduling and interrupts from interfering with data coherency. On Linux, we now no longer require a full-blown interrupt lock, but instead are looking for a way to lock out all other threads within our process from running to avoid data coherency issues. Fortunately, we are only targeting single-core execution (by use of starting our process with a taskset command to set CPU affinity). Of course, it would probably be best to look at all of the specific hazards and use cases of this in our codebase, and replace them with more specific synchronization items (eg, mutexes, etc.). But, this is naturally a large codebase that makes such that difficult to achieve. So, given the following: 1. We only run on a single CPU core (via taskset) 2. Nothing on the system (or at least our process) is given an RT priority of 99 3. SCHED_DEADLINE is not used 4. PI does not occur (ie, this "critical section" code must never use a mutex) 5. RT throttling does not occur 6. Interrupts or preemption from the kernel is allowed, just not from threads in our process a) Would there be any real synchronization hazards with temporarily boosting a thread's priority to 99? (Does changing a thread's priority on the fly guarantee immediate usage of the new priority for scheduling?) b) Or, can one always safely expect that the SCHED_FIFO thread with 99 priority will not be preempted (if not, what situations might present a hazard?)? c) Are there any obvious alternatives to just boosting priority? Thanks! Seth Opgenorth -- IMPORTANT: The information contained in this transmission may be privileged, proprietary and confidential and protected from disclosure. It is intended only for the intended recipient. If you are not the intended recipient or a person responsible for delivering this transmission to the intended recipient, you may not disclose, copy or distribute this transmission or take any action in reliance on it. If you received this transmission in error, please notify us immediately by replying to this message and please dispose of and delete this transmission. Thank you. Yaskawa America, Inc.
