From owner-freebsd-current  Tue Mar 11 08:23:46 1997
Return-Path: <owner-current>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id IAA16546
          for current-outgoing; Tue, 11 Mar 1997 08:23:46 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA16532
          for <current@freebsd.org>; Tue, 11 Mar 1997 08:23:36 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id DAA20223; Wed, 12 Mar 1997 03:16:27 +1100
Date: Wed, 12 Mar 1997 03:16:27 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199703111616.DAA20223@godzilla.zeta.org.au>
To: bde@zeta.org.au, brian@shift.lan.awfulhak.org
Subject: Re: ppp
Cc: ache@nagual.ru, brian@awfulhak.demon.co.uk, brian@utell.co.uk,
        current@freebsd.org
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>&= ~ isn't guaranteed atomic ?  Yeuch.  I'd tend to go with Andrey's

Nothing is guaranteed to be atomic in C.  The closest it gets is
objects of type sig_atomic_t, which can safely be set (but not read)
in signal handlers.

>suggestion that I use an int array rather than a bit array.  I assume
>that ++ and -- are guaranteed to be atomic (if they're not, I'm in *lots*
>of trouble).

No, ++ and -- guaranteed to be atomic.  They are good candidates for
splitting up into read/modify/write so that they can be pipelined better.
In practice, the i386 version of gcc is usually too stupid to do this.

The kernel handles the corresponding problems for interrupts by using
assembler code to get instructions that are known to be atomic.  It
could also use some form of locking, but locking tends to be slower.
Kernel locking using splhigh()/splx() corresponds exactly to
sigprocmask(SIG_BLOCK...)/sigprocmask(SIG_SETMASK...).

Bruce