Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Mar 1997 16:41:10 +0000
From:      Brian Somers <brian@shift.lan.awfulhak.org>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        ache@nagual.ru, brian@awfulhak.demon.co.uk, brian@utell.co.uk, current@freebsd.org
Subject:   Re: ppp 
Message-ID:  <199703111641.QAA27876@shift.lan.awfulhak.org>
In-Reply-To: Your message of "Wed, 12 Mar 1997 03:16:27 %2B1100." <199703111616.DAA20223@godzilla.zeta.org.au> 

next in thread | previous in thread | raw e-mail | index | archive | help
> >&= ~ 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.

Oh boy, I've written *lots* of code in the past that assumes ++ and --
to be atomic - I kinda assumed that it had to reduce to an inc or dec,
but then, I've seen some of the assembler output by gcc before - and
it's the best compiler I've seen.  Oh well, you learn something new.....

> >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

I think the sigprocmask stuff is impractical.  It would take a relatively
long time to SIG_BLOCK all the signals before altering caused each time.

I'll do without.  The only thing that can happen as a result is a lost
signal, and that's what I'd get on a slow machine anyway.  At least
the code will be handling practically all latencies introduced by the
pending signal.
-- 
Brian <brian@awfulhak.demon.co.uk> <brian@freebsd.org>
      <http://www.awfulhak.demon.co.uk>;
Don't _EVER_ lose your sense of humour !





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703111641.QAA27876>