9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Russ Cox" <rsc@swtch.com>
To: 9fans@cse.psu.edu
Subject: [9fans] new system calls - semacquire, semrelease
Date: Thu, 23 Mar 2006 19:43:46 -0500	[thread overview]
Message-ID: <8cdf39c7acd3dea54d564e218a675229@swtch.com> (raw)

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.



             reply	other threads:[~2006-03-24  0:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-24  0:43 Russ Cox [this message]
2006-03-24  0:52 ` Bruce Ellis
2006-03-25  4:50   ` William Josephson
2006-03-25  6:46     ` Bruce Ellis
2006-03-25  9:22     ` Charles Forsyth
2006-03-25 16:04       ` Bruce Ellis
2006-03-25 16:12         ` Russ Cox
2006-03-26  7:27           ` Lyndon Nerenberg
2006-03-26 17:11             ` Bruce Ellis
2006-03-26 18:59               ` Charles Forsyth

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=8cdf39c7acd3dea54d564e218a675229@swtch.com \
    --to=rsc@swtch.com \
    --cc=9fans@cse.psu.edu \
    /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).