|
From: William G. <app...@li...> - 2016-02-06 04:19:40
|
Hi all, I am writing a tool for multi-threaded debugging. I have inserted a helper with instruemntation (addStmtToIRSB( sbOut, IRStmt_Dirty(di) );). The helper stores data in a table. 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? Thanks guys! |
|
From: Ivo R. <iv...@iv...> - 2016-02-06 10:33:44
|
2016-02-06 5:07 GMT+01:00 William Good <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. |
|
From: Philippe W. <phi...@sk...> - 2016-02-14 17:57:08
|
On Sat, 2016-02-06 at 11:33 +0100, Ivo Raisr wrote: > 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. The prototype was a 'real prototype', i.e. trying to explore possibilities/problems/issues/... . So, no, in the current state, there is nothing that can be committed. Philippe |
|
From: William G. <app...@li...> - 2016-02-07 03:22:37
|
Thanks for your response I. Very helpful slides. As a follow up question is it possible to use thread local storage in a valgrind tool? ________________________________ From: Ivo Raisr <iv...@iv...> Sent: Saturday, February 6, 2016 5:33:36 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. |
|
From: Philippe W. <phi...@sk...> - 2016-02-14 18:00:18
|
On Sun, 2016-02-07 at 03:10 +0000, William Good wrote: > > Thanks for your response I. Very helpful slides. As a follow up > question is it possible to use thread local storage in a valgrind > tool? > ______________________________________________________________________ When I prototyped a 'parallel valgrind', I did some trials of using thread local storage : TLS variables started to work on linux, but nothing tried/examined for Android or MacOs. Again, nothing that can be committed. Philippe |
|
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. |
|
From: Ivo R. <iv...@iv...> - 2016-02-10 01:55:20
|
2016-02-09 19:57 GMT+01:00 William Good <app...@li...>: > 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? > I assume your helper function is called from within the translated code, right? Then your helper is always executed within a context of a basic block. And the big lock guarantees that no context switch happens during the invocation of a basic block. If that was not the case, we would be in a huge trouble today. I. |