Dear Marc,
Our proposal is to provide one flag for the threads (as before)
and one for the locking to be able to built a
ROOT with threads, but without the locking. Nobody is forced to
compile it in that way. If you like it with threads and locking
you can build it this way. To have a separate lock flag would be
a fair option for sites where the application does the locking
already. We do not expect binaries of all versions. So, it costs nothing.
A library can be either thread save or not. I do not know how to use it
if it is only 70% thread save. If there is a 100% threadsave ROOT
we will measure the performance, but up to now I do not see this
already achieved.
Greetings,
Hans
Dear Hans,
regarding to your wish, in my opinion, we should keep it as the ROOT
teamers did it. The struggle in the last years was always to make ROOT
thread-safe. Now we are approaching this goal more and more. I would not
recommend any additional flag to make ROOT "really" thread-safe.
With your proposal we get the "normal" ROOT, the "thread-safe" ROOT and
the "really thread-safe" ROOT. Or am I misinterpreting your proposal?
I know, that this leads to some additional work on the application side,
but as it was foreseeable that ROOT has to do something in this respect,
and as it was discussed already some months ago with you, Joern, Mathieu
and Fons, how the ROOT team will proceed, it was no real surprise.
It would be really a good idea to have test cases to answer your
question. But as you told me privately, how can the thread-safety else
be approved except by an analytical approach.
Greetings,
Marc
Essel Dr.Hans-Georg wrote:
>Dear ROOT teamers,
>the following is said in the release notes of 3.03/08 about thread safety:
>......
>Patch from Mathieu de Naurois adding Thread-safety in many ROOT classes.
>A new TVirtualMutex global is defined in TVirtualMutex.h (gCINTmutex).
>The gCINTMutes is used in TMethodCall to protect concurrent access to CINT.
>The R__LOCKGUARD macro is introduced in many classes to check for a mutex.
>The performance penalty introduced by the MUTEX logic
> -is ZERO in the application has no threads
> -about 10% in case of threads
>......
>Just one strong wish and one question:
>The wish:
>There are already multi-threaded ROOT based programs running. Obviously
they
>managed already the necessary locking on application level. These are now
>punished by the way
>the LOCKGUARD is implemented, because it depends on _REENTRANT, which in
>turn is set when
>you build ROOT with threads.
>Why do the programs mentioned above not throw away their locking, now we
>have LOCKGUARD?
>Well, first it may be a question of developer time, second, see the
question
>below.
>
>We propose unstead to separate the activation of the LOCKGUARD by using an
>extra keyword.
>
>The question:
>What does it mean: "Thread-safety in many ROOT classes"?
>So far TStorage, TCollection, TCint, TClass, TMethodCall and TThread
itself.
>Is with these the ROOT class library now thread-save or not?
>E.g. whats about modifications of the global lists and directories?
>
>Thanks,
>
>Hans
>
--
Dr. Marc Hemberger
/\_/\
( o.o )
> ^ <
|\ _,,,---,, EMBL
ZZZzz /,`.-'`' -. ;-;;,_ C&N Group
|,4- ) )-,_. ,\ ( `'-' Meyerhofstr. 1
'---''(_/--' `-'\_) 69117 Heidelberg
Germany privat:
Marc.Hemberger@embl-heidelberg.de MHemberger@csi.com
** Disclaimer: My views/comments/beliefs, as strange as they are, are my
own.**
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:51:06 MET