|
From: Panagiotis F. <paf...@gm...> - 2012-03-13 14:47:41
|
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?
Regards,
Panagiotis Foteinos
|
|
From: WAROQUIERS P. <phi...@eu...> - 2012-03-13 15:54:32
|
> 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? Can't too much comment about the above, but you could compare with the helgrind output, and see if this confirms the race condition. Philippe ____ This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender. |
|
From: Panagiotis F. <paf...@gm...> - 2012-03-13 15:12:59
|
Thank you for the reply. No, helgrind does not confirm it. I guess there is nothing wrong at these lines. Regards, Panagiotis On Tue, Mar 13, 2012 at 11:06 AM, WAROQUIERS Philippe <phi...@eu...> wrote: > >> 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? > Can't too much comment about the above, but you could compare with > the helgrind output, and see if this confirms the race condition. > > Philippe > > ____ > > This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. > > Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy. > > Any views expressed in this message are those of the sender. |
|
From: Bart V. A. <bva...@ac...> - 2012-03-13 17:30:00
|
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.
|