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

From: Valentin Bonnard (Bonnard.V_at_[hidden])
Date: 2000-09-02 20:39:26

On Sat, Sep 02, 2000 at 08:57:15AM +0100, Kevlin Henney wrote:
> 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.

So explain me why. I really don't see the difference.

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

So there are no specific reasons ?

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

What Greg posted is the dual of guaranty: if you don't do that 
they are no guaranties. Does it count as a guaranty (if you do 
that, there are guaranties) ? Or is a signal handler expected 
to behave like any other C++ function, except for specific 
exceptions (types other than volatile sig_atomic_t, etc.) ?

I tend to think that the correct interpretation is the latter, 
but this is a strange way of writting specifications.

-- 
Valentin Bonnard