|
From: Hamid R. K. <kha...@gm...> - 2012-03-23 13:10:28
|
Hi, I have some questions about Valgrind tool. I would be thankful if answer me. 1- I want to know does Valgrind support Pthread and openMP programs? 2- I need a tool that traces my multi-threaded program and creates memory trace of the program. The trace must contain accessed memory address, threadID and access type(Read/Write). Sorry to bother you with my questions. |
|
From: Eliot M. <mo...@cs...> - 2012-03-23 13:22:05
|
On 3/23/2012 9:10 AM, Hamid Reza Khaleghzadeh wrote: > Hi, > > I have some questions about Valgrind tool. I would be thankful if answer me. > > 1- I want to know does Valgrind support Pthread and openMP programs? > 2- I need a tool that traces my multi-threaded program and creates > memory trace of the program. The trace must contain accessed memory > address, threadID and access type(Read/Write). > > Sorry to bother you with my questions. It does support multiple threads, but runs only one thread at a time. I don't personally know the answer to the OpenMP question. For a memory trace, you can take and extend the lackey tool slightly to have it output the thread id in addition to the type of reference, the address, and the number of bytes referenced. That should be a straightforward change if you can find where to get the thread id in valgrind. (I've not looked for that information, but system call tracing in valgrind certainly prints it, so it should not be hard to get.) Regards -- Eliot Moss |
|
From: Julian S. <js...@ac...> - 2012-03-23 17:45:38
|
On Friday, March 23, 2012, Eliot Moss wrote: > On 3/23/2012 9:10 AM, Hamid Reza Khaleghzadeh wrote: > > Hi, > > > > I have some questions about Valgrind tool. I would be thankful if answer > > me. > > > > 1- I want to know does Valgrind support Pthread and openMP programs? > > 2- I need a tool that traces my multi-threaded program and creates > > memory trace of the program. The trace must contain accessed memory > > address, threadID and access type(Read/Write). > > > > Sorry to bother you with my questions. > > It does support multiple threads, but runs only one thread at a time. > I don't personally know the answer to the OpenMP question. OpenMP programs run, sure. They are "just another" threaded app from V's point of view. > For a memory trace, you can take and extend the lackey tool > slightly to have it output the thread id in addition to the type > of reference, the address, and the number of bytes referenced. > That should be a straightforward change if you can find where > to get the thread id in valgrind. You can either call VG_(get_running_tid) all the time (slow), or ask the core to notify you of thread switches via VG_(track_start_client_code)( evh__start_client_code ); VG_(track_stop_client_code)( evh__stop_client_code ); (see hg_main.c) which is obviously much faster, but the downside is you have to believe what the core tells you, which I sometimes doubt :) J |
|
From: Eliot M. <mo...@cs...> - 2012-03-23 17:04:45
|
On 3/23/2012 12:21 PM, Hamid Reza Khaleghzadeh wrote: > Hi Dear Eliot, I added valgrind-users back so that all can follow the email thread. > Thanks for your answer. You said that "Valgrind does support multiple threads, but runs only one > thread at a time." > Suppose a two threaded application. The threads run in parallel. Suppose thread1 read A, thread2 > simultaneously write A, and thread1 read A again. In this case, records of output trace are as > following (holds order of access) ? > Thread1 read A > Thread2 write A > Thread1 read A It depends on whether the scheduler swaps threads at the two places indicated. Perhaps it will help to think of the trace as being what you might get from running your multi-thread program on a single cpu, where the operating system periodically switches between runnable threads. In fact, valgrind will try to switch when the underlying OS does. However, for various reasons valgrind tends to emulate the execution of whole sequences of instructions in one go, and such thread switching will not happen in the middle of a sequence. Thus if Thread1 reads A twice in the *same* such sequence, you will never see Thread2 do anything between the two reads. You may be able to control with your instrumentation where the sequences end, but performance will be very bad if you end them at every read and write. Also, you still get each thread normally running for a full scheduler quantum before a switch will be attempted. In sum, you should get one *possible* execution, but it won't necessarily be one typical of truly concurrent execution. (Just because you have threads that are *runnable* at the same time does not mean that they actually run *concurrently* in a real system, unless you guarantee multuple cpus are available. You can think of valgrind as providing a universe where only one cpu is *ever* available.) There are many good reasons why valgrind is this way; it would be substantially more difficult to build (and maintain!) a similar tool that supported true concurrency. > Thanks for your answer in advance. No problem. Eliot Moss |
|
From: Julian S. <js...@ac...> - 2012-03-23 17:51:17
|
> In sum, you should get one *possible* execution, but it won't necessarily > be one typical of truly concurrent execution. (Just because you have > threads that are *runnable* at the same time does not mean that they > actually run *concurrently* in a real system, unless you guarantee > multuple cpus are available. You can think of valgrind as providing a > universe where only one cpu is *ever* available.) You can get round robin scheduling of runnable threads using --fair-sched=yes. And you can change the quantum to something a lot lower by changing this value ./coregrind/m_scheduler/scheduler.c:#define SCHEDULING_QUANTUM 100000 to (eg) 1000. Performance will be a lot worse, but you'll get much finer grained interleaving. Note that when https://bugs.kde.org/show_bug.cgi?id=296422 lands it will somewhat reduce this effect, since one minor effect of it is to reduce the number of event (timeslice-out) checks by about a factor of 3. J |
|
From: Siddharth N. <si...@gm...> - 2012-12-07 23:56:24
|
Hi All, Is there are theoretical situation where a single thread could repeatedly be trying to acquire a lock (as dictated by the user program) or will Valgrind switch this thread out or will the Linux system detect this and intervene successfully? Futexes don't do system calls until there is sufficient contention. There will not be sufficient contention when threads are serialized correct? So with no system calls, Valgrind will not really have a reason to switch a thread out even when it is not really doing much other than waiting on a lock. Is this correct? Sid On 23 March 2012 13:45, Julian Seward <js...@ac...> wrote: > >> In sum, you should get one *possible* execution, but it won't necessarily >> be one typical of truly concurrent execution. (Just because you have >> threads that are *runnable* at the same time does not mean that they >> actually run *concurrently* in a real system, unless you guarantee >> multuple cpus are available. You can think of valgrind as providing a >> universe where only one cpu is *ever* available.) > > You can get round robin scheduling of runnable threads using > --fair-sched=yes. And you can change the quantum to something a lot > lower by changing this value > > ./coregrind/m_scheduler/scheduler.c:#define SCHEDULING_QUANTUM 100000 > > to (eg) 1000. Performance will be a lot worse, but you'll get much > finer grained interleaving. > > Note that when https://bugs.kde.org/show_bug.cgi?id=296422 lands > it will somewhat reduce this effect, since one minor effect of it is > to reduce the number of event (timeslice-out) checks by about a factor of 3. > > J > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |