Thread safe root classes

Hi,

is there any overview which classes are/are not currently thread safe?

Cheers,
Miro

Dear Miro,

such a document is not yet available. On the other hand, a pragmatic alternative is available and is represented by the multicore tutorials, where the expression of parallelism within ROOT is reviewed via concrete examples: root.cern/doc/master/group__tut … icore.html

Cheers,
Danilo

Hi,

now I’m having a concrete problem I do not really understand:

[quote]Number of threads: 7
Number of threads: 7
Number of threads: 7
Number of threads: 1
Wall Time = 1.72234606743
CPU Time = 7.393376
loading intermediate
Number of threads: 1

*** Break *** segmentation violation

===========================================================
There was a crash.
This is the entire stack trace of all threads:

print "Pretty STL & QT Activated"
                                ^

Thread 7 (Thread 0x7f7682278700 (LWP 4052)):
#0 0x00007f7686bf3b72 in ?? () from /usr/lib/x86_64-linux-gnu/libgomp.so.1
#1 0x00007f7686bf235e in ?? () from /usr/lib/x86_64-linux-gnu/libgomp.so.1
#2 0x00007f7685b7c184 in start_thread (arg=0x7f7682278700) at pthread_create.c:312
#3 0x00007f768670937d in clone () at …/sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 6 (Thread 0x7f7681a77700 (LWP 4053)):
#0 0x00007f7686bf3b72 in ?? () from /usr/lib/x86_64-linux-gnu/libgomp.so.1
#1 0x00007f7686bf235e in ?? () from /usr/lib/x86_64-linux-gnu/libgomp.so.1
#2 0x00007f7685b7c184 in start_thread (arg=0x7f7681a77700) at pthread_create.c:312
#3 0x00007f768670937d in clone () at …/sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 5 (Thread 0x7f7681276700 (LWP 4054)):
#0 0x00007f7686bf3b72 in ?? () from /usr/lib/x86_64-linux-gnu/libgomp.so.1
#1 0x00007f7686bf235e in ?? () from /usr/lib/x86_64-linux-gnu/libgomp.so.1
#2 0x00007f7685b7c184 in start_thread (arg=0x7f7681276700) at pthread_create.c:312
#3 0x00007f768670937d in clone () at …/sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 4 (Thread 0x7f7680a75700 (LWP 4057)):
#0 0x00007f7686bf3b72 in ?? () from /usr/lib/x86_64-linux-gnu/libgomp.so.1
#1 0x00007f7686bf235e in ?? () from /usr/lib/x86_64-linux-gnu/libgomp.so.1
#2 0x00007f7685b7c184 in start_thread (arg=0x7f7680a75700) at pthread_create.c:312
#3 0x00007f768670937d in clone () at …/sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 3 (Thread 0x7f7680274700 (LWP 4059)):
#0 0x00007f7686bf3b72 in ?? () from /usr/lib/x86_64-linux-gnu/libgomp.so.1
#1 0x00007f7686bf235e in ?? () from /usr/lib/x86_64-linux-gnu/libgomp.so.1
#2 0x00007f7685b7c184 in start_thread (arg=0x7f7680274700) at pthread_create.c:312
#3 0x00007f768670937d in clone () at …/sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 2 (Thread 0x7f767fa73700 (LWP 4061)):
#0 0x00007f7686bf3b72 in ?? () from /usr/lib/x86_64-linux-gnu/libgomp.so.1
#1 0x00007f7686bf235e in ?? () from /usr/lib/x86_64-linux-gnu/libgomp.so.1
#2 0x00007f7685b7c184 in start_thread (arg=0x7f767fa73700) at pthread_create.c:312
#3 0x00007f768670937d in clone () at …/sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 1 (Thread 0x7f7688f1ab80 (LWP 4048)):
#0 0x00007f76866cfa59 in __libc_waitpid (pid=4107, stat_loc=stat_loc
entry=0x7fff307a3440, options=options
entry=0) at …/sysdeps/unix/sysv/linux/waitpid.c:40
#1 0x00007f7686655232 in do_system (line=) at …/sysdeps/posix/system.c:148
#2 0x00007f7688a31553 in TUnixSystem::StackTrace (this=0x29c4000) at /home/iwsatlas1/mgabriel/Downloads/root-6.08.00/core/unix/src/TUnixSystem.cxx:2403
#3 0x00007f7688a33f5c in TUnixSystem::DispatchSignals (this=0x29c4000, sig=kSigSegmentationViolation) at /home/iwsatlas1/mgabriel/Downloads/root-6.08.00/core/unix/src/TUnixSystem.cxx:3661
#4
#5 0x0000000000471e5e in Run::LoadIntFiles (this=0x7fff307a5c20) at src/Run.cxx:281
#6 0x0000000000471b86 in Run::LoadRawData (this=0x7fff307a5c20) at src/Run.cxx:200
#7 0x000000000048a511 in main (argc=1, argv=0x7fff307a60a8) at calibration.cxx:161

The lines below might hint at the cause of the crash.
You may get help by asking at the ROOT forum root.cern.ch/forum.
Only if you are really convinced it is a bug in ROOT then please submit a
report at root.cern.ch/bugs. Please post the ENTIRE stack trace
from above as an attachment in addition to anything else
that might help us fixing this issue.

#5 0x0000000000471e5e in Run::LoadIntFiles (this=0x7fff307a5c20) at src/Run.cxx:281
#6 0x0000000000471b86 in Run::LoadRawData (this=0x7fff307a5c20) at src/Run.cxx:200
#7 0x000000000048a511 in main (argc=1, argv=0x7fff307a60a8) at calibration.cxx:161

:~/workspace/claws_phaseI/claws_calibration$ [/quote]

I’m running something in a parallel loop with:

Which seems to work (couting the Number of threads 7). This part is than finished and the program switches to 1 thread again (couting the Number of threads 1). In the single thread part I’m than running the following code:

What I do not understand, why are multiple threads appearing in the error message in a part of the code with only one thread? And why is the method failing in general? I’m running the exact same code in the single thread region like I did before. It seems like root is still “sensing” the threads and getting into trouble?

Cheers,
Miro

Hi Miro,

the threads are there since the openmp runtime manages them (see the library associated to them). GDB is working correctly and informing us of this while dumping the stacktrace.
Do you have a minimal reproducer for your failure?

Cheers,
Danilo