Milind kmil...@gmail.com writes:
Thanks for the quick reply Tom.
I (again) went over the para that you have pointed out. Most of the
discussion in that para and the Helgrind discussion seem to revolve
around single CPU. I am not seeing any references to multicore
system with concurrent running of threads . Multiple threads,
synchronization between them, deadlocks etc all seem to be talking in
the context of a single CPU. Hope I am not misreading.
I think the discussion in that paragraph is pretty clear: valgrind
will never cause a threaded program to behave incorrectly according to
the POSIX spec, but you get 0 concurrency the time slicing will be
different.
I am looking for collecting memory traces for a multicore,
multithreaded (hw threads) program.
I think you need to look somewhere else.
Side note to the valgrind devs: does the documentation need to be
updated here? The last paragraph in Support for Threads (linked
below) says that the use of atomic instruction sequences in shared
memory between processes will not work reliably, yet the 3.5.0
release notes say that the lock prefix on certain instructions is
now respected [1]. Due to the ambiguity between threads and processes
(i.e., clone), I'm not sure if this is referring to shared address
spaces in threads (in which case it probably needs updating) or atomic
instructions on data in sysv/posix shmem -- i.e. shm_open'd memory.
I've never heard of anyone using the latter, but then again I don't
interact with many people that use even posix shared memory anyway.
-tom
[1] http://valgrind.org/docs/manual/dist.news.html
On Thu, Jan 7, 2010 at 6:06 AM, tom fogal tfo...@alumni.unh.edu wrote:
Milind kmil...@gmail.com writes:
[snip]
I am writing an application that will run on a system that
has multiple CPU cores and each core having multiple hardware
threads. With multiple CPU cores there will be simultaneous memory
access requests.
I would like to know
- whether Valgrind supports multicore systems ?
- if so, how accurately does it trace the memory accesses ?
- if there is anyone who has already used such multicore, multiple hw
thread
environment to trace memory accesses ?
http://www.valgrind.org/docs/manual/manual-core.html#manual-core.pthreads
Cheers,
-tom
--00504502c7adb3382d047c89ec87
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Thanks for the quick reply Tom.brbrI (again) went over the para that yo=
u have pointed out. Most of the discussion in that para and the Helgrind di=
scussion seem to revolve around single CPU. I am not seeing any references =
to multicore system with concurrent running of threads . Multiple threads, =
synchronization between them, deadlocks etc all seem to be talking in the c=
ontext of a single CPU. Hope I am not misreading.br
brI am looking for collecting memory traces for a multicore, multithreade=
d (hw threads) program.brbrThanks,br- Milindbrbrdiv class=3Dgma=
il_quoteOn Thu, Jan 7, 2010 at 6:06 AM, tom fogal span dir=3Dltrlt;=
a href=3Dmailto:tfo...@alumni.unh.edu;tfo...@alumni.unh.edu/agt;/span=
wrote:br
blockquote class=3Dgmail_quote style=3Dborder-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;Milind lt;a hre=
f=3Dmailto:kmil...@gmail.com;kmil...@gmail.com/agt; writes:br
[snip]br
div class=3Dimgt; I am writing an application that will run on a syste=
m thatbr
gt; has multiple CPU cores and each core having multiple hardwarebr
gt; threads. With multiple CPU cores there will be simultaneous memorybr
gt; access requests.br
gt;br
gt; I would like to knowbr
gt; - whether Valgrind supports multicore systems ?br
gt; - if so, how accurately does it trace the memory accesses ?br
gt; - if there is anyone who has already used such multicore, multiple hw =
threadbr
gt; environment to trace memory accesses ?br
br
/div =A0a href=3Dhttp://www.valgrind.org/docs/manual/manual-core.html#m=
anual-core.pthreads target=3D_blankhttp://www.valgrind.org/docs/manual/=
manual-core.html#manual-core.pthreads/abr
br
Cheers,br
font color=3D#88br
-tombr
/font/blockquote/divbr
--00504502c7adb3382d047c89ec87--
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users