[cpp-threads] Does pthread_mutex_lock() have release emantics?

[jimmaureenrogers at att.net]

--
Jim Rogers 
Colorado Springs, Colorado 
U.S.A.


-------------- Original message from "Boehm, Hans" <hans.boehm at hp.com>: -------------- 
> If we want to make it possible to prohibit this, I think we need 
> to move to a different, more complicated, definition of a data 
> race, which explicitly talks about a happens-before relation, 
> as in the Java case. We probably need to do that anyway if we want 
> to precisely define the different ordering constraints in the 
> atomic operations library. If we think synchronization primitives 
> should behave as though nothing were reordered around them, then we 
> might try to preserve the current simpler definition for the 
> core of the language, and confine the added complexity to the 
> atomic operations library. 
> 
> Opinions? 

I have been quiet in this discussion because of my lack of knowledge of the C++
standard. I did get curious, however, when reading the discussion about race
conditions and pthreads.

My past simple recommendations included a high-level threading syntax for
C++ similar in abstraction level to those implemented in Java or Ada.

I took a look through the Ada Language Reference Manual for the 1995
version of Ada, paying particular attention to Section 9. "Tasks and Synchronization".
The Ada Reference Manual does not try to define race conditions. It also does not
deal with the inversion of lock logic demonstrated by Hans' example. This is one
advantage of a high level abstraction. You can completely avoid low level 
inversions of abstraction.

While it is true that Ada has a much stronger model for separation of specification
and implementation than does C++, the following opinions may still be useful.
Ada tasks are a symantic equivalent to threads. Direct task interactions are only
possible through clearly specified interfaces in each task. Those interfaces are called
"entries" in Ada. Entries are used for synchronous direct communication between tasks.
Entries of one task can be called conditionally from another task. Entries can be associated
with a boundary condition. Entries can be conditionally handled by the called task. Race
conditions are possible when using entries. Race conditions can be predicted through the
use of Rate Monotonic Analysis (RMA) of the source code. RMA is performed by tools
separate from the compiler.

Ada provides protected objects for safe use of shared memory areas between tasks.
Protected objects are allowed to have three kinds of methods: Procedures, Entries, and
Functions. All locking and unlocking of the protected object is implicitly handled through
the call interfaces to the different methods. Procedures acquire an unconditional write lock
on the protected object when they start executing, and release the lock at the end of their
execution. Entries acquire a conditional write lock on the protected object and release
the lock at the end of their execution. Functions acquire a read lock on the protected object.
Multiple tasks may simultaneously call the same or different functions on a single protected
object because protected functions are defined as read-only operations on the protected
object. Read locks can be implemented in a manner similar to counting semaphores. The
read lock is released when no more function calls are active.

Race conditions can occur using any locking scheme if a circular dependency of entries
is called. Such a circular dependency design is always an error. Ada allows erroneous
programs to fail. A call circularity that results in a race condition or a deadlock is often
easier to avoid than to create.

Ada provides volatile and atomic qualifiers for unsynchronized shared data. There are
very few cases where the use of unsyncrhonized shared data is actually a good idea.

Since each thread, or Ada task, is a separate sequence of execution, do you really
need to worry about changing the definition of sequence points? There are always 
going to be timing issues between threads that allow several threads to access a lock
in an unpredictable order.

Jim Rogers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shadbolt.decadentplace.org.uk/pipermail/cpp-threads/attachments/20050507/8ced7115/attachment.html