Re: [boost] Re: Threads: Atomic Counter (sig_atomic_t)

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2000-09-02 10:28:45

From: Kevlin Henney <kevlin_at_[hidden]>
> In message <20000902013848.04281_at_[hidden]>, Valentin Bonnard
> <Bonnard.V_at_[hidden]> writes
> >On Fri, Sep 01, 2000 at 09:39:34AM +0100, Kevlin Henney wrote:
> >> And the only things they do "promise" are related to signals, not to
> >> threading.
> >
> >That's the same thing !
> 
> I assure you, it is not.
> 
> >> Introducing a dependency on <csignal> would be misleading
> >> (threads and signals interact _badly_) and incorrect :-}
> >
> >(signals interact badly with almost everything)
> 
> But particularly with threads. A number of years ago, whilst POSIX.4a
> was in draft (around draft 10 I think), I was working on a system that
> used pthreads. The interaction between threads and signals was poorly
> specified and one of the more volatile elements of the standard.
> 
> >Why do you think that a shared unprotected (ie w/o locks) variable 
> >of type volatile sig_atomic_t can't be used for inter-thread 
> >communication ?
>
> Because the standard does not say they can. Simple really ;-)

Which means what matters is how your threads are acually
implemented, what your compiler actually does, what your
hardware actually does, what your needs for syncronization
are.  For portability you have to assume the worst.

> >(BTW, I haven't been able to find specific guaranties about 
> >sig_atomic_t in the C++ standard; are they hidden in the C 
> >standard ? In particular, is sig_atomic_t()++ guarantied 
> >to be atomic ?)
> 
> No such guarantee exists. Greg pretty much posted all the guarantees you
> get.
> ____________________________________________________________
> 
>   Kevlin Henney                   phone:  [phone]
>   Curbralan Ltd                   mobile: [phone]
>   kevlin_at_[hidden]            fax:    [phone]
> ____________________________________________________________
> 
> 
> 
>