[Libsigcx-main] Re: [sigc] Re: [gtkmm] libsigcx and gtkmm 2.4

[Martin S. <mar...@hi...>]

Am 14.06.2004 19:34:41 schrieb(en) Christer Palm:
> Daniel Elstner wrote:
>> 
>> Okay, you're (partly) right.  ("Partly" because it's not "locking or
>> unlocking": what's needed is unlock in thread A and lock in thread  
>> B.)
>> I found this in Butenhof:
>> 
>>         Whatever memory values a thread can see when it unlocks a  
>> mutex,
>>         either directly or by waiting on a condition variable, can  
>> also
>>         be seen by any thread that later locks the same mutex.   
>> Again,
>>         data written after the mutex is unlocked may not necessarily  
>> be
>>         seen by the thread that locks the mutex, even if the write
>>         occurs before the lock.
>> 
>> In other words, the sequence
>> 
>>         pthread_mutex_lock(mutex);
>>         pthread_mutex_unlock(mutex);
>> 
>> issues a memory barrier instruction on the unlock.  The other thread
>> that wants to read the data still has to lock the same mutex though.
>>
> 
> A memory barrier, or synchronize, instruction is issued both on lock  
> and unlock and also in a bunch of other thread related functions. Of  
> course all threads need to agree on which mutex protects memory  
> location X, that's how they make sure they doesn't execute a region  
> of code that access memory location X simultaneously. Not because  
> only certain memory locations are syncronized then the mutex is  
> locked/unlocked.
> 
> Having said that, is there any place in mine or Martins code where  
> you believe that this rule isn't followed, except as a side effect of  
> passing objects that contain internal references?
> 
> 
> This is what IEEE Std 1003.1-2004 has to say about memory  
> synchronization requirements:
> 
>  4.10 Memory Synchronization
> 
> Applications shall ensure that access to any memory location by more  
> than one thread of control (threads or processes) is restricted such  
> that no thread of control can read or modify a memory location while  
> another thread of control may be modifying it. Such access is  
> restricted using functions that synchronize thread execution and also  
> synchronize memory with respect to other threads. The following  
> functions synchronize memory with respect to other threads:
> 
> ...
> pthread_mutex_lock()
> ...
> pthread_mutex_unlock()
> ...

This gives rise to an interesting question: If no locking is required  
(e.g. because atomic operations are used), which is the most efficient  
call to establish a memory barrier (e.g. before doing the atomic  
operation)? In a linux driver, I would call wmb(), but what can I do on  
the application side? Signal a dummy condition?

Regards,

  Martin