Another version of the problem statement (FYI)

[Boehm, Hans]

Maged -

I think the official party line is that "volatile" in C
was designed to support IO operations and doesn't say
much about inter-thread visibility.  See, for example:

http://www.talkaboutprogramming.com/group/comp.programming.threads/messages/41517.html

(David Butenhof is one of the pthreads designers and a book
author.  He now also works for HP.  But we only very partially
agree on these issues.  I sent him a copy of the paper, but
haven't gotten back any flames yet.)

But I think the details are unclear and controversial, as you
can also see from that discussion.

In particular, I have no idea what volatile bit-fields
mean.  There is often no way to update these without
rewriting adjacent fields.  And that seems to be near the
core of this issue.  (I think bit-fields inherently
have to be treated differently in the memory model,
and currently no standard seems to make that distinction.)

As a practical matter, volatile is sometimes helpful, though
the semantics vary widely across platforms.  (On IA64, you get
something close to the Java semantics.  On some other platforms,
volatile and ordinary accesses are not reordered by the compiler,
on some they are.)

For the first example in the paper, volatiles wouldn't help, since
the current pthread spec doesn't mention volatile.  It does make it
less likely that a real compiler would introduce a race, but you
still need to define what constitutes a race.  I think there are no
C implementations for which volatile accesses are sequentially
consistent, though that's true (among other things) for Java 1.5.

For the second and third examples, the programs in question
are fully synchronized with locks.  The only real way
to avoid these issues, if you assume that "volatile"
avoids the transformations, would be to declare all
shared variables volatile, even if they're protected
by locks.  I think that's impractical because:

a) There exist zillions of lines of code that don't.

b) It is common practice to take a sequential library
and wrap a lock around it.  (Sometimes you may need a
single lock to protect multiple libraries due to silly
non-reentrant library functions.)  This no longer
works, since you would have to declare library-internal
variables volatile.

c) It's inconsistent with Java, and I'm reasonably sure
we can teach the average programmer at most one set of
concurrent programming rules.  (Some variation is OK.  But
I think completely different approaches should be avoided
if possible.)

Hans


-----Original Message-----
From: Maged Michael [mailto:magedm at us.ibm.com]
Sent: Tuesday, November 16, 2004 12:17 PM
To: Boehm, Hans
Cc: Andrei Alexandrescu; Ben Hutchings; Doug Lea; Boehm, Hans; Kevlin Henney; pugh at cs.umd.edu
Subject: Re: Another version of the problem statement (FYI)



Hi Hans, 

It was nice seeing you in ISMM. I enjoyed reading the paper. I have a question not related to the main point of the paper (that threads cannot be implemented as a library). My question is about the semantics of volatile in C. My understanding (I am not absolutely sure) is that volatile prohibits the compiler from omitting or adding accesses to volatile variables, although the compiler may reorder accesses to different volatile variables. So, in each of the three examples in Section 4, if the relevant variables are declared as volatile (and by using memory ordering instructions or functions if needed), wouldn't the problems go away? 

Maged 



"Boehm, Hans" <hans.boehm at hp.com> 
11/15/2004 05:20 PM         
        To:        Maged Michael/Watson/IBM at IBMUS, "Andrei Alexandrescu" <andrei at metalanguage.com>, "Ben Hutchings" <ben at decadentplace.org.uk>, "Doug Lea" <dl at altair.cs.oswego.edu>, "Kevlin Henney" <kevlin at curbralan.com>, <pugh at cs.umd.edu> 
        cc:        "Boehm, Hans" <hans.boehm at hp.com> 
        Subject:        Another version of the problem statement (FYI)



I ended up submitting the attached paper to PLDI.  Whether or not it's
accepted there, it will be HP technical report HPL-2004-209.

This is very similar to the critique of the C/C++ + Pthreads model that
I posted earlier, and that I talked about at the Dagstuhl workshop
some of us went to.  Only this version is thought out and written a bit
more carefully.

Comments are of course welcome.

Hans 


#### tr209.pdf has been removed from this note on November 16, 2004 by Maged Michael