Linux-rt-users Archive on lore.kernel.org
 help / color / Atom feed
* 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)
  To: linux-rt-users

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.

^ 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 \
		linux-rt-users@vger.kernel.org
	public-inbox-index linux-rt-users

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-rt-users


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git