Re: light weight user level semaphores

["Alon Ziv" <alonz@nolaviz.org>]

Hmm...
I already started (long ago, and abandoned since due to lack of time :-( )
down another path; I'd like to resurrect it...

My lightweight-semaphores were actually even simpler in userspace:
* the userspace struct was just a signed count and a file handle.
* Uncontended case is exactly like Linus' version (i.e., down() is decl +
js, up() is incl()).
* The contention syscall was (in my implementation) an ioctl on the FH; the
FH was a special one, from a private syscall (although with the new VFS I'd
have written it as just another specialized FS, or even referred into the
SysVsem FS).

So, there is no chance for user corruption of kernel data (as it just ain't
there...); and the contended-case cost is probably equivalent (VFS cost vs.
validation).

Hope I inspired someone...

    -az

----- Original Message -----
From: "Ulrich Drepper" <drepper@redhat.com>
To: "Linus Torvalds" <torvalds@transmeta.com>
Cc: "Mike Kravetz" <mkravetz@sequent.com>; "Kernel Mailing List"
<linux-kernel@vger.kernel.org>
Sent: Wednesday, April 18, 2001 21:35
Subject: Re: light weight user level semaphores


> Linus Torvalds <torvalds@transmeta.com> writes:
>
> Sounds good so far.  Some comments.
>
> >  - FS_create is responsible for allocating a shared memory region
> >    at "FS_create()" time.
>
> This is not so great.  The POSIX shared semaphores require that an
> pthread_mutex_t object placed in a shared memory region can be
> initialized to work across process boundaries.  I.e., the FS_create
> function would actually be FS_init.  There is no problem with the
> kernel or the helper code at user level allocating more storage (for
> the waitlist of whatever) but it must not be necessary for the user to
> know about them and place them in share memory themselves.
>
> The situation for non-shared (i.e. intra-process) semaphores are
> easier.  What I didn't understand is your remark about fork.  The
> semaphores should be cloned.  Unless the shared flag is set there
> should be no sharing among processes.
>
>
> The rest seems OK.  Thanks,
>
> --
> ---------------.                          ,-.   1325 Chesapeake Terrace
> Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
> Red Hat          `--' drepper at redhat.com   `------------------------
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>