This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Thread-, Signal- and Cancellation-safety documentation


On Thu, May 30, 2013 at 11:58:21AM -0300, Alexandre Oliva wrote:
> > At least http://www.unix.org/whitepapers/reentrant.html states:
> 
> > In POSIX.1c, a "reentrant function" is defined as a "function whose
> > effect, when called by two or more threads, is guaranteed to be as if
> > the threads each executed the function one after another in an undefined
> > order, even if the actual execution is interleaved" (ISO/IEC
> > 9945:1-1996, Â2.2.2).
> 
> > That hints at some (total?) order.
> 
> Err...  Do I misread âundefined orderâ there? :-)
> 
> That's what I meant by âno ordering guaranteesâ.  It looks like we're
> suffering out of differences in the meanings of terms.
> 
> To me, ordering requirements has to do establishing a happens-before
> relationship.

I would avoid reading old versions of Unix/POSIX specs for these
definitions. At that time, ordering and memory model were very poorly
thought-out concepts, and as you can see even "reentrant" is defined
wrong. This was fixed in POSIX 2008, which has much better wording and
statement of the memory model, but it's still inferrior to C11's
specification of the memory model.

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]