[9fans] new system calls - semacquire, semrelease

[9fans] new system calls - semacquire, semrelease

[Russ Cox]

There are two new system calls today, documented
in the man page below.  As the man page says,
they are intended as building blocks, not to be used by
regular programs.  The functionality they provide is not
far from possible to implement with rendezvous(2), but
the crucial difference is that semrelease has no qlocks
and thus is guaranteed not to block the calling process*,
making it suitable to use in real-time processes to wake
up non-real-time processes.  Sape is using this to good
effect in an internal app.

These semaphores are actually a more convenient building
block than rendezvous for implementing things like qlock,
channels, and rsleep/rwakeup.  For compatibility with
older kernels, we're leaving those alone.  Maybe in a year
or two.

See /sys/src/9/port/sysproc.c for more information.

Russ


* Of course, semrelease will block if *addr is swapped
out, but if you're using real-time processes, you're
not swapping anyway.



     SEMACQUIRE(2)                                       SEMACQUIRE(2)

     NAME
          semacquire, semrelease - user level semaphores

     SYNOPSIS
          #include <u.h>
          #include <libc.h>

          int semacquire(long *addr, int block);

          long semrelease(long *addr, long count);

     DESCRIPTION
          Semacquire and semrelease facilitate scheduling between pro-
          cesses sharing memory.  Processes arrange to share memory by
          using rfork with the RFMEM flag (see fork(2)), segattach(2),
          or thread(2).

          The semaphore's value is the integer pointed at by addr.
          Semacquire atomically waits until the semaphore has a posi-
          tive value and then decrements that value.  It returns 1 if
          the semaphore was acquired and -1 on error (e.g., if it was
          interrupted).  If block is zero and the semaphore is not
          immediately available, semacquire returns 0 instead of wait-
          ing.  Semrelease adds count to the semaphore's value and
          returns the new value.

          Semacquire and semrelease can be thought of as efficient,
          correct replacements for:

               int
               semacquire(long *addr, int block)
               {
                    while(*addr == 0){
                         if(!block)
                              return 0;
                         if(interrupted)
                              return -1;
                    }
                    --*addr;
                    return 1;
               }

               int
               semrelease(long *addr, int count)
               {
                    return *addr += count;
               }

          Like rendezvous(2), semacquire and semrelease are not typi-
          cally used directly.  Instead, they are intended to be used
          to coordinate scheduling in higher-level abstractions such
          as locks, rendezvous points, and channels (see lock(2) and
          thread(2)). Also like rendezvous , semacquire and semrelease
          cannot be used to coordinate between threads in a single
          process.  Use locks, rendezvous points, or channels instead.

     SOURCE
          /sys/src/9/port/sysproc.c

     SEE ALSO
          fork(2), lock(2), rendezvous(2), segattach(2), thread(2)

     DIAGNOSTICS
          These functions set errstr.

Re: [9fans] new system calls - semacquire, semrelease

[Bruce Ellis]

a bit like ...

	semnew:		fn(n: int): ref Sem;
	semacquire:	fn(s: ref Sem);
	semcanacq:	fn(s: ref Sem): int;
	semrelease:	fn(s: ref Sem);

in ozinferno

On 3/24/06, Russ Cox <rsc@swtch.com> wrote:
> There are two new system calls today, documented
> in the man page below.  As the man page says,
> they are intended as building blocks, not to be used by
> regular programs.  The functionality they provide is not
> far from possible to implement with rendezvous(2), but
> the crucial difference is that semrelease has no qlocks
> and thus is guaranteed not to block the calling process*,
> making it suitable to use in real-time processes to wake
> up non-real-time processes.  Sape is using this to good
> effect in an internal app.
>
> These semaphores are actually a more convenient building
> block than rendezvous for implementing things like qlock,
> channels, and rsleep/rwakeup.  For compatibility with
> older kernels, we're leaving those alone.  Maybe in a year
> or two.
>
> See /sys/src/9/port/sysproc.c for more information.
>
> Russ
>
>
> * Of course, semrelease will block if *addr is swapped
> out, but if you're using real-time processes, you're
> not swapping anyway.
>
>
>
>     SEMACQUIRE(2)                                       SEMACQUIRE(2)
>
>     NAME
>          semacquire, semrelease - user level semaphores
>
>     SYNOPSIS
>          #include <u.h>
>          #include <libc.h>
>
>          int semacquire(long *addr, int block);
>
>          long semrelease(long *addr, long count);
>
>     DESCRIPTION
>          Semacquire and semrelease facilitate scheduling between pro-
>          cesses sharing memory.  Processes arrange to share memory by
>          using rfork with the RFMEM flag (see fork(2)), segattach(2),
>          or thread(2).
>
>          The semaphore's value is the integer pointed at by addr.
>          Semacquire atomically waits until the semaphore has a posi-
>          tive value and then decrements that value.  It returns 1 if
>          the semaphore was acquired and -1 on error (e.g., if it was
>          interrupted).  If block is zero and the semaphore is not
>          immediately available, semacquire returns 0 instead of wait-
>          ing.  Semrelease adds count to the semaphore's value and
>          returns the new value.
>
>          Semacquire and semrelease can be thought of as efficient,
>          correct replacements for:
>
>               int
>               semacquire(long *addr, int block)
>               {
>                    while(*addr == 0){
>                         if(!block)
>                              return 0;
>                         if(interrupted)
>                              return -1;
>                    }
>                    --*addr;
>                    return 1;
>               }
>
>               int
>               semrelease(long *addr, int count)
>               {
>                    return *addr += count;
>               }
>
>          Like rendezvous(2), semacquire and semrelease are not typi-
>          cally used directly.  Instead, they are intended to be used
>          to coordinate scheduling in higher-level abstractions such
>          as locks, rendezvous points, and channels (see lock(2) and
>          thread(2)). Also like rendezvous , semacquire and semrelease
>          cannot be used to coordinate between threads in a single
>          process.  Use locks, rendezvous points, or channels instead.
>
>     SOURCE
>          /sys/src/9/port/sysproc.c
>
>     SEE ALSO
>          fork(2), lock(2), rendezvous(2), segattach(2), thread(2)
>
>     DIAGNOSTICS
>          These functions set errstr.
>
>

Re: [9fans] new system calls - semacquire, semrelease

[William Josephson]

On Fri, Mar 24, 2006 at 11:52:38AM +1100, Bruce Ellis wrote:
> a bit like ...
>
> 	semnew:		fn(n: int): ref Sem;
> 	semacquire:	fn(s: ref Sem);
> 	semcanacq:	fn(s: ref Sem): int;
> 	semrelease:	fn(s: ref Sem);
>
> in ozinferno

Interesting...  Say, is ozinferno available?
Sounds like it might be interesting to poke at it.

Re: [9fans] new system calls - semacquire, semrelease

[Bruce Ellis]

there are licensing issues so i haven't released it.

and if i just throw the source out then there will be horrible
merges of me and vn.

i'll release a binary soon (renovating now)  ... it has got
pretty swift - one step at a time.  the garbage collector rulez.

i'm spending too much time working on Guido- dis on a fpga.
and basking in the sun and eating good seafood.

brucee

On 3/25/06, William Josephson <jkw@eecs.harvard.edu> wrote:
> On Fri, Mar 24, 2006 at 11:52:38AM +1100, Bruce Ellis wrote:
> > a bit like ...
> >
> >       semnew:         fn(n: int): ref Sem;
> >       semacquire:     fn(s: ref Sem);
> >       semcanacq:      fn(s: ref Sem): int;
> >       semrelease:     fn(s: ref Sem);
> >
> > in ozinferno
>
> Interesting...  Say, is ozinferno available?
> Sounds like it might be interesting to poke at it.
>

Re: [9fans] new system calls - semacquire, semrelease

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 231 bytes --]

there is lock(2) in the public inferno distribution.  the implementation is amusing.
things like counting semaphores have been too, though not distributed,
but these things are not used as much as channels in Limbo programming.

[-- Attachment #2: Type: message/rfc822, Size: 3129 bytes --]

From: William Josephson <jkw@eecs.harvard.edu>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] new system calls - semacquire, semrelease
Date: Fri, 24 Mar 2006 23:50:45 -0500
Message-ID: <20060325045045.GA13159@mero.morphisms.net>

On Fri, Mar 24, 2006 at 11:52:38AM +1100, Bruce Ellis wrote:
> a bit like ...
>
> 	semnew:		fn(n: int): ref Sem;
> 	semacquire:	fn(s: ref Sem);
> 	semcanacq:	fn(s: ref Sem): int;
> 	semrelease:	fn(s: ref Sem);
>
> in ozinferno

Interesting...  Say, is ozinferno available?
Sounds like it might be interesting to poke at it.

Re: [9fans] new system calls - semacquire, semrelease

[Bruce Ellis]

indeed al this stuff can be one with channels but locks are
often easier, paryicularly if nested.

	newlock:	fn(): ref Lock;
	lock:		fn(l: ref Lock);
	rlock:		fn(l: ref Lock);
	canlock:	fn(l: ref Lock): int;
	canrlock:	fn(l: ref Lock): int;
	unlock:		fn(l: ref Lock);

brucee

On 3/25/06, Charles Forsyth <forsyth@terzarima.net> wrote:
> there is lock(2) in the public inferno distribution.  the implementation is amusing.
> things like counting semaphores have been too, though not distributed,
> but these things are not used as much as channels in Limbo programming.
>
>
>
> ---------- Forwarded message ----------
> From: William Josephson <jkw@eecs.harvard.edu>
> To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
> Date: Fri, 24 Mar 2006 23:50:45 -0500
> Subject: Re: [9fans] new system calls - semacquire, semrelease
> On Fri, Mar 24, 2006 at 11:52:38AM +1100, Bruce Ellis wrote:
> > a bit like ...
> >
> >       semnew:         fn(n: int): ref Sem;
> >       semacquire:     fn(s: ref Sem);
> >       semcanacq:      fn(s: ref Sem): int;
> >       semrelease:     fn(s: ref Sem);
> >
> > in ozinferno
>
> Interesting...  Say, is ozinferno available?
> Sounds like it might be interesting to poke at it.
>
>

Re: [9fans] new system calls - semacquire, semrelease

[Russ Cox]

> there is lock(2) in the public inferno distribution.  the implementation is amusing.

much like the old trick of storing a byte in a pipe
and using it as an interprocess lock.

the implementation of the plan 9 semaphore code,
by the way, is a bit more involved than one might
first expect.  the hard part is accessing *addr safely
without using a qlock (which would block) in semrelease.
(and you can't access *addr while holding a lock
either, since you're not allowed to touch user memory
while holding locks.)  i verified it with spin to double-check.

russ

Re: [9fans] new system calls - semacquire, semrelease

[Lyndon Nerenberg]

On Mar 25, 2006, at 8:12 AM, Russ Cox wrote:

> much like the old trick of storing a byte in a pipe
> and using it as an interprocess lock.

It's a brilliant trick. It let us write some very portable code (to
windows, too, no less) with almost no effort.  Don't knock
inginuity.  (Or insanity.  But that's just labels ...)

--lyndon

Re: [9fans] new system calls - semacquire, semrelease

[Bruce Ellis]

boyd would put keys in pipes so core dumps (incidental or nasty)
wouldn't give them away.  interesting to think about, given my
current plumbing problems (water not bytes).

brucee

On 3/26/06, Lyndon Nerenberg <lyndon@orthanc.ca> wrote:
>
> On Mar 25, 2006, at 8:12 AM, Russ Cox wrote:
>
> > much like the old trick of storing a byte in a pipe
> > and using it as an interprocess lock.
>
> It's a brilliant trick. It let us write some very portable code (to
> windows, too, no less) with almost no effort.  Don't knock
> inginuity.  (Or insanity.  But that's just labels ...)
>
> --lyndon
>

Re: [9fans] new system calls - semacquire, semrelease

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 591 bytes --]

here's a different little hack that's more unix-specific,
which i borrowed from unix libthread (i think that's where i saw it,
although it might be well-known in fcntl land).

a parent process needs to know whether a child has successfully done an exec
of an arbitrary program (so it's hard to have that program tell the parent).
the parent makes a pipe, marks the child's end as close-on-exec, forks, and then
reads its end of the pipe.  if the exec succeeds, the read returns 0; if the
exec fails, the child writes the diagnostic on the pipe, so again the read returns something.

[-- Attachment #2: Type: message/rfc822, Size: 3609 bytes --]

From: "Bruce Ellis" <bruce.ellis@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: [9fans] new system calls - semacquire, semrelease
Date: Mon, 27 Mar 2006 03:11:45 +1000
Message-ID: <775b8d190603260911h73f5b3ceqb03c5724ab95f6fb@mail.gmail.com>

boyd would put keys in pipes so core dumps (incidental or nasty)
wouldn't give them away.  interesting to think about, given my
current plumbing problems (water not bytes).

brucee

On 3/26/06, Lyndon Nerenberg <lyndon@orthanc.ca> wrote:
>
> On Mar 25, 2006, at 8:12 AM, Russ Cox wrote:
>
> > much like the old trick of storing a byte in a pipe
> > and using it as an interprocess lock.
>
> It's a brilliant trick. It let us write some very portable code (to
> windows, too, no less) with almost no effort.  Don't knock
> inginuity.  (Or insanity.  But that's just labels ...)
>
> --lyndon
>