From: Hubertus Franke <frankeh@watson.ibm.com>
To: Martin Wirth <Martin.Wirth@dlr.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Lightweight userspace semphores
Date: Wed, 27 Feb 2002 10:24:46 -0500 [thread overview]
Message-ID: <20020227102446.A838@elinux01.watson.ibm.com> (raw)
In-Reply-To: <3C7C9C41.5080400@dlr.de>
In-Reply-To: <3C7C9C41.5080400@dlr.de>; from Martin.Wirth@dlr.de on Wed, Feb 27, 2002 at 09:43:45AM +0100
On Wed, Feb 27, 2002 at 09:43:45AM +0100, Martin Wirth wrote:
> Hi Hubertus,
>
> I just had a quick look on your semaphore code. As far as I can see you
> do no re-check of the userspace semaphore counter while going to sleep
> on your kernel semaphore. But this way you may loose synchronization
> between the kernel semaphore and the user-space semaphore counter if
> more than two processes are involved. Or did I miss some tricky form
> of how you avoided this problem?
>
> Martin Wirth
Yes, you are missing something.
I assume you are looking at the usema (non spinning version).
The trick is that the kernel semaphore stores a token in case a race
condition occurs and it will resolve it that way.
I rely on the fact that the kernel only provides a wait queue nothing
else, the entire state on how many are waiting are stored in user space.
Effectively you have a P operation in user space followed by a P operation
in kernel space. Same for V operation.
Assuming you have two or more processes 0,1,2 ... you can show
that race conditions are properly resolved. Again, the trick is to not
sync the state of the kernel and the user level. It comes naturally
if you properly separate the duties.
The spinning versions were much more interesting, you can really have
some tricky situations for 3 or more processes. The ulockflex program
really helped to identify problems.
In future messages please point out which of the user locks are in question.
Remember I provide several:
(1) semaphores
(2) semaphores with timed spinning
(3) convoy avoidance locks
(4) convoy avoidance locks with spinning
(5) shared locks == multiple reader/single writer locks
This list is growing as we speak.
I also modified the code (I will post the update at the lse site).
This also fixes a small bug in the ulockflex program, that I introduced
in the last posting at lse.
I took Ben LaHaises suggestions and provide multiple runqueues
up to a limit, rather then explicitely coding exclusive/shared version.
next prev parent reply other threads:[~2002-02-27 15:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-27 8:43 Martin Wirth
2002-02-27 15:24 ` Hubertus Franke [this message]
2002-02-27 17:17 ` Martin Wirth
2002-02-27 19:04 ` Hubertus Franke
[not found] ` <3C7FDF76.9040903@dlr.de>
2002-03-02 14:08 ` [PATCH] Lightweight userspace semaphores Hubertus Franke
2002-03-03 22:13 ` [Lse-tech] " Paul Jackson
2002-03-04 16:07 ` Hubertus Franke
2002-03-04 6:13 ` Rusty Russell
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=20020227102446.A838@elinux01.watson.ibm.com \
--to=frankeh@watson.ibm.com \
--cc=Martin.Wirth@dlr.de \
--cc=linux-kernel@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
all inboxes | Powered by JetHome®