|
From: William G. <app...@li...> - 2016-02-09 18:57:51
|
Kind thanks for your response. From reading Philippe's slides I see that a thread will release the big lock "After it has executed 100K basic blocks". This does not necessarily guarantee that there will be no context switches inside my helper function (addStmtToIRSB( sbOut, IRStmt_Dirty(di) ). It seems like a lock is still necessary to protect my data structure. If this is the case how do I go about protecting my table from thread races? ________________________________ From: Ivo Raisr <iv...@iv...> Sent: Saturday, February 6, 2016 5:33 AM To: William Good Cc: val...@li... Subject: Re: [Valgrind-developers] Using lock in tool 2016-02-06 5:07 GMT+01:00 William Good <app...@li...<mailto:app...@li...>>: The table needs to be thread safe because different threads will be using it at run time. I cannot use a pthread_mutex in my tool, correct? How can I make a lock for the table? Hi Bill, Valgrind runs properly multi-threaded applications, but effectively only uses one vCPU at a time to run them. In other words, Valgrind does not use multiple CPUs when running a multi-threaded application. So far no Valgrind analysis tool (except 'none') is designed such that it is multi-thread safe. They all leverage the fact there is always single thread running. See Philippe's presentation about multi-thread Valgrind prototype from FOSDEM 2015: https://archive.fosdem.org/2015/schedule/event/valgrind_multi_prototype/ It goes to a great length in what and where is not multi-thread safe and how come Valgrind is able to run multi-thread applications properly. An ideal situation would be if Valgrind core provides efficient synchronization mechanisms which all analysis tools can consume. Maybe Philippe could comment if there is anything usable from his prototype. I. |