* Linux-rt scheduling - task lock equivalents?
@ 2020-10-05 23:18 Seth Opgenorth
0 siblings, 0 replies; only message in thread
From: Seth Opgenorth @ 2020-10-05 23:18 UTC (permalink / raw)
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
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
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
c) Are there any obvious alternatives to just boosting priority?
IMPORTANT: The information contained in this transmission may be
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
please dispose of and delete this transmission.
Yaskawa America, Inc.
^ permalink raw reply [flat|nested] only message in thread
only message in thread, back to index
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-05 23:18 Linux-rt scheduling - task lock equivalents? Seth Opgenorth
Linux-rt-users Archive on lore.kernel.org
Archives are clonable:
git clone --mirror https://lore.kernel.org/linux-rt-users/0 linux-rt-users/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 linux-rt-users linux-rt-users/ https://lore.kernel.org/linux-rt-users \
Example config snippet for mirrors
Newsgroup available over NNTP:
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git