linux-rt-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Seth Opgenorth <seth_opgenorth@yaskawa.com>
To: "linux-rt-users@vger.kernel.org" <linux-rt-users@vger.kernel.org>
Subject: Linux-rt scheduling - task lock equivalents?
Date: Mon, 5 Oct 2020 16:18:17 -0700	[thread overview]
Message-ID: <CAP7GL9MV7AxW9sv2G1D5AYjEJfhwv7=nM6kbj2Qk78ss7wtp4A@mail.gmail.com> (raw)

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.

                 reply	other threads:[~2020-10-05 23:18 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAP7GL9MV7AxW9sv2G1D5AYjEJfhwv7=nM6kbj2Qk78ss7wtp4A@mail.gmail.com' \
    --to=seth_opgenorth@yaskawa.com \
    --cc=linux-rt-users@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).