[cpp-threads] pthreads (was: RE: C++ Connections proposal)

[Boehm, Hans]

Alexander -

Our group decided, and the C++ committee tentatively concurred,
that we should go with an approach of

a) Defining data races precisely (a language/compiler issue), and
b) Guaranteeing sequential consistency for data-race-free programs
while leaving everything else undefined.  This is similar only in spirit
to the Java model.

There are some other issues that your proposal below doesn't address.
For details, see my upcoming PLDI paper, which, as of five minutes ago,
is cited from the page at

http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/

Hans

> -----Original Message-----
> From: 
> Cpp-threads_decadentplace.org.uk-bounces at decadentplace.org.uk 
> [mailto:Cpp-threads_decadentplace.org.uk-bounces at decadentplace
> .org.uk] On Behalf Of Alexander Terekhov
> Sent: Monday, April 25, 2005 10:56 AM
> To: cpp-threads at decadentplace.org.uk; Peter Dimov
> Subject: Re: [cpp-threads] pthreads (was: RE: C++ Connections 
> proposal)
> 
> 
> On 4/25/05, Peter A. Buhr <pabuhr at plg.uwaterloo.ca> wrote:
> 
> [...] 
> 
> > pthreads solves the problem by throwing away performance to gain
> > correctness, which I have pointed out is the necessary trade off.
> 
> I agree that pthreads is broken. But I think that it can be fixed. 
> 
> Memory isolation aside for a moment, pls see
> 
> http://www.opengroup.org/austin/mailarchives/ag-review/msg01865.html
> http://www.opengroup.org/austin/mailarchives/ag-review/msg01867.html
> http://www.opengroup.org/austin/mailarchives/ag-review/msg01869.html
> http://www.opengroup.org/austin/mailarchives/ag-review/msg01870.html
> http://www.opengroup.org/austin/mailarchives/ag-review/msg01871.html
> http://www.opengroup.org/austin/mailarchives/ag-review/msg01872.html
> http://www.opengroup.org/austin/mailarchives/ag-review/msg01875.html
> http://www.opengroup.org/austin/mailarchives/ag-review/msg01877.html
> 
> All but one DR referenced above are still hanging "open". The 
> last version of my XBD 4.10 edit is this:
> 
> -----
> Applications shall ensure that access to any memory location by more 
> than one thread is restricted such that no thread can read or modify 
> a memory location while another thread of control may be 
> modifying it. 
> Applications shall use functions listed below that synchronize thread 
> execution and ensure that modifications to locations in memory are 
> ordered with respect to accesses to the same memory locations 
> in other 
> threads. There is a happens-before inter-thread ordering with respect 
> to preceding (in program and inter-thread order) modifications of 
> memory locations in
> 
>   a thread calling pthreads_create() and accesses to modified memory 
>   locations in the created thread;
> 
>   a thread calling fork() and accesses to modified memory locations 
>   in the initial thread of the created process;
> 
>   a terminated thread and accesses to modified memory locations in 
>   another thread in the same process after that thread returns from 
>   pthread_join() joining the terminated thread, or in another thread 
>   in a parent process after that thread returns from wait() or 
>   waitpid() observing terminated status of a child process;
> 
>   a thread calling sem_post() on a specified semaphore and accesses 
>   to modified memory locations in another thread after that thread 
>   calls sem_wait() or sem_trywait() or sem_timedwait() and 
>   locks the same semaphore unlocked by the calling thread, or 
>   another thread observes the incremented semaphore value of the 
>   same semaphore by calling sem_getvalue();
> 
>   a thread calling sem_wait() or sem_trywait() or sem_timedwait() 
>   decrementing semaphore value of a specified semaphore and accesses 
>   to modified memory locations in another thread after that thread 
>   observes the decremented semaphore value of the same semaphore 
>   using sem_getvalue();
> 
>   < XSI IPC semas... >
> 
>   < realtime signals? sigvalue is a union with pointer... >
> 
>   a thread calling pthread_spin_unlock() on a specified spin lock 
>   and accesses to modified memory locations in another thread 
>   after that thread calls pthread_spin_lock() or 
>   pthread_spin_trylock() and locks the same spin lock unlocked by 
>   the calling thread;
> 
>   a thread calling pthread_rwlock_unlock() on a specified read-
>   write lock releasing a write lock and read accesses to modified 
>   memory locations in another thread after that thread acquires a 
>   read lock using pthread_rwlock_rdlock() or 
>   pthread_rwlock_timedrdlock() or pthread_rwlock_tryrdlock() on 
>   the same read-write lock unlocked by the calling thread; 
> 
>   a thread calling pthread_rwlock_unlock() on a specified read-
>   write lock releasing a write lock and read/write accesses to 
>   modified memory locations in another thread after that thread 
>   acquires a write lock using pthread_rwlock_timedwrlock() or 
>   pthread_rwlock_trywrlock() or pthread_rwlock_wrlock() on 
>   the same read-write lock unlocked by the calling thread; 
> 
>   a thread calling pthread_mutex_unlock() on a specified mutex 
>   and accesses to modified memory locations in another thread 
>   after that thread calls pthread_mutex_lock() or 
>   pthread_mutex_timedlock() or pthread_mutex_trylock() and locks 
>   the same mutex unlocked by the calling thread or when another
>   thread locks the same mutex unlocked by the calling thread 
>   and returns from a call to pthread_cond_wait() or 
>   pthread_cond_timedwait();
> 
>   a thread calling pthread_cond_wait() or pthread_cond_timedwait() 
>   and accesses to modified memory locations in another thread 
>   after that thread calls pthread_mutex_lock() or 
>   pthread_mutex_timedlock() or pthread_mutex_trylock() and locks 
>   the same mutex unlocked by the calling thread or when another
>   thread locks the same mutex unlocked by the calling thread 
>   and returns from a call to pthread_cond_wait() or 
>   pthread_cond_timedwait();
> 
>   a thread calling pthread_barrier_wait() on a specified barrier 
>   and accesses to modified memory locations in another thread 
>   after that thread returns from pthread_barrier_wait() call on 
>   the same specified barrier on the same or later barrier cycle;
> 
>   a thread calling pthread_once() on a specified pthread_once_t 
>   object returning from a specified init_routine and accesses to 
>   modified memory locations in another thread after that thread 
>   returns from pthread_once() on the same pthread_once_t object.
> 
> Functions listed above and also pthread_cond_signal() and 
> pthread_cond_broadcast() are all side effects.
> 
> Conforming applications are said to be data race-free.
> -----
> 
> In the past, POSIX folks refused to address the use of 
> undefined term "memory location". "Language issue," they say. 
> Fixing that problem and extending POSIX data-race free model 
> with atomic<> and msync reordering constraints/labels (all 
> unidirectional apart from bidirectional msync::{sl}fence() 
> barrier functions) 
> for operations on competing atomic<> calls (that's in addition 
> to noncompeting and/or "exclusive" accesses) is the way to go. 
> First step, so to speak. The next step is ADA-like higher level 
> stuff along the lines of protected objects. But that's C++1X, 
> I'm afraid. Just my 0.2 euros.
> 
> regards,
> alexander.
> 
> -- 
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk 
> http://decadentplace.org.uk/mailman/listinfo/cpp-threads_decad
entplace.org.uk