Re: [Valgrind-users] Hard to interpret the race

[Bart V. A. <bva...@ac...>]

On 03/13/12 14:47, Panagiotis Foteinos wrote:
> Hello grinders.
>
> So, I find it difficult to see the race. Below, the valgrind DRD output follows:
>
> **************************************************************
> Conflicting load by thread 1 at 0x1221c91c size 4
> ==4907==    at 0x5B7028: Parallel_Mesh_Generation::try_lock(Vertex*,
> int) (Parallel_Mesh_Generation.cxx:2224)
> ......
>
>  Other segment start (thread 9)
> ==4907==    at 0x4C352A0: pthread_mutex_unlock (drd_pthread_intercepts.c:665)
> ==4907==    by 0x5CB1E9: boost::mutex::unlock() (mutex.hpp:61)
> ==4907==    by 0x5C96DE: Parallel_Mesh_Generation::UpdateNewCells(int,
> Simple_Containers::Vector<Cell*>&) (Parallel_Mesh_Generation.cxx:8909)
> ==4907==    by 0x5B3FC7: Parallel_Mesh_Generation::client_insert(int
> const&, Point const&, Cell*) (Parallel_Mesh_Generation.cxx:790)
>
> Other segment end (thread 9)
> ==4907==    at 0x6E13464: __lll_lock_wait (lowlevellock.S:136)
> ==4907==    by 0x6E0E5D8: _L_lock_953 (pthread_mutex_lock.c:117)
> ==4907==    by 0x6E0E3F9: pthread_mutex_lock (pthread_mutex_lock.c:61)
> ==4907==    by 0x4C362AF: pthread_mutex_lock (drd_pthread_intercepts.c:614)
> ==4907==    by 0x5CB182: boost::mutex::lock() (mutex.hpp:52)
> ==4907==    by 0x5C9661: Parallel_Mesh_Generation::UpdateNewCells(int,
> Simple_Containers::Vector<Cell*>&) (Parallel_Mesh_Generation.cxx:8900)
> ==4907==    by 0x5B3FC7: Parallel_Mesh_Generation::client_insert(int
> const&, Point const&, Cell*) (Parallel_Mesh_Generation.cxx:790)
> **************************************************************
>
> According to DRD, there is a race when thead 1 is at line 2224, and
> thread 9 is at the lines 8900-8909, correct?
>
> Below, the relevant code lines are attached:
>
> **************************************************************
> Thread 1:
> if(v->thread_id == thread_id)
>     //line 2224
> **************************************************************
>
> and
> **************************************************************
> Thread 9:
> 	this->utilization_mtx.lock();
>  //line 8900
> 	if(this->threads_without_work != 0)
> 	{
> 		this->threads_without_work--;
>
> #ifdef REPORT_COUNTERS
> 		(*this->begging_list_not_empty[thread_id])++;
> #endif
> 		other_id = this->beggers[(this->beg_index_start++)%this->number_of_threads];
> 		this->utilization_mtx.unlock();                         //line 8909
> **************************************************************
>
> The variable "thread_id" in Thread 9 is local to its stack. It has
> nothing to do with either "v->thread_id"  or "thread_id" of Thread 1.
> Is this a false positive, or the drd message says something else?

It might be a race on v or v->thread_id as well. A convenient way to
analyze this further is to insert DRD_TRACE_VAR(thread_id) in the
constructor of the object v points at and to insert
DRD_TRACE_VAR(thread_id) just after the declaration of the thread_id
stack variable(s).

Bart.