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

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-09-02 02:57:15

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

>(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]
____________________________________________________________