According to the helgrind manual "When a mutex is unlocked by thread T1 and
later (or immediately) locked by thread T2, then the memory accesses in T1
prior to the unlock must happen-before those in T2 after it acquires the lock".
Two possible ways to interpret this:
Scenario #1:
int shared_value;
pthread_mutex_t lock;
Thread 1:
pthread_mutex_lock(&lock);
shared_value = 10;
pthread_mutex_unlock(&lock);
Thread 2:
pthread_mutex_lock(&lock);
... = shared_value;
pthread_mutex_unlock(&lock);
For this, no data race on shared_value should be reported;
Scenario #2:
pthread_mutex_t lock;
int* shared_ptr;
Thread 1:
int* my_ptr = new int;
*my_ptr = 10;
pthread_mutex_lock(&lock);
shared_ptr = my_ptr;
pthread_mutex_unlock(&lock);
Thread 2:
pthread_mutex_lock(&lock);
int* my_ptr = shared_ptr;
pthread_mutex_unlock(&lock);
... = *my_ptr;
In this case, there should be no data race on shared_ptr, similar to scenario
#1. Will helgrind report a data race on the memory shared_ptr points to, or is
memory only deemed to be safe while a semaphore is locked.
Phil
-----
Phil Longstaff
Senior Software Engineer
x2904
------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
