Re: Is ROOT threadsafe?

Hi Fons.
> Alas, not much has changed in the respect. The biggest issue is that CINT
> and X11 are not thread safe. So everything that goes via CINT or X11 has
> to be processed in the main thread, or has to be explicitly locked. Many

are you sure that X11 is not thread safe? When I made TThread implementation
many years ago, even simple printf() caused crash, but now I saw a lot of code
with thread and I/O and no crash4es any more.

Victor

Victor M. Perevoztchikov perev_at_bnl.gov Brookhaven National Laboratory MS 510A
PO Box 5000, Upton, NY 11973-5000
Tel: office 631-344-7894; fax 631-344-4206 ----- Original Message -----
From: "Fons Rademakers" <Fons.Rademakers_at_cern.ch> To: "Konstantin Olchanski" <olchansk_at_triumf.ca> Cc: <roottalk_at_cern.ch>
Sent: Wednesday, February 02, 2011 4:26 AM Subject: Re: [ROOT] Is ROOT threadsafe?

> Hi Konstantin,
>
>
> On 01/02/2011 18:14, Konstantin Olchanski wrote:
>>
>>
>> Hi, rooters - what is the latest situation with thread safety in ROOT?
>>
>> I have an application that uses a separate thread to grab ROOT objects
>> created
>> by end users (TH1& ilk), serialize them and send them over a TCP
>> connection
>> to a different application (happily single-threaded, where users look at
>> these objects).
>>
>> It's a poor man's substitute for PAW/HBOOK shared memory histograms and
>> it is used
>> mainly to look at live data produced by the MIDAS data acquisition
>> system.
>> http://midas.psi.ch
>> http://daq-plone.triumf.ca/SR/rootana
>>
>> All this was written some years ago, the ROOT world has moved on since
>> then
>> and now time has come to renew my code and I am not sure if my thread
>> implementation
>> is correct for the latest versions of ROOT.
>>
>> So I look at the documentation and do not see happy results:
>>
>> 1) user guide v5.26 introduces TThread::Lock and Unlock, but does not
>> spell out which
>> ROOT operations have to be locked and which are thread safe. The text
>> also
>> says that "parts of ROOT are not thread safe yet" (search for word
>> "yet"). This implies
>> that some unspecified parts of ROOT are thread-safe after all and
>> promises
>> that other parts will become thread-safe. I cannot tell if this text is
>> up to date,
>> so what's the current situation?
>>
>
> Alas, not much has changed in the respect. The biggest issue is that CINT
> and X11 are not thread safe. So everything that goes via CINT or X11 has
> to be processed in the main thread, or has to be explicitly locked. Many
> containers have locks too, but which specific methods are locked is not
> properly documented in the reference guide. If you look in the code you
> will see statements like:
>
> R__LOCKGUARD2(gCollectionMutex);
>
> which is used to lock a collection operation (typically in TCollection,
> TSeqCollection, etc). Just make a search for R__LOCKGUARD in the ROOT
> sources. Clearly this is an area that needs much better documentation.
>
>> 2) tutorials/thread/threadsh1.C is one of the few examples of using
>> threads
>> and it uses TThread::Lock inconsistently. For example it does not lock
>> calls
>> to gRandom - is that one part of ROOT that is thread safe? Also in the
>> sub-thread,
>> calls to canvas->cd() and th1->Draw() are locked, but canvas->Modified()
>> is not;
>> and the main thread does not seem to lock anything at all. If this
>> example is correct at all,
>> it implies that some implicit locking is happening somewhere else?
> >
> For threadsh1 locking gRandom is not critical so not done.
> TCanvas::Modified() just sets a bool so no locking needed. Basically
> locking is only needed for operations that actually draw (via X11).
>>
>> So what looking do I need to do in my thread?
>>
>> I use things like tobject->InheritsFrom(), gRoot->FindObjectAny(),
>> th1->Reset(),
>> tdirectory->GetList(), new TKey(...), tobject->GetName(),
>> TMessage, TList, TSocket (TSocket I believe is thread-safe),
>> tdirectory->GetListOfKeys(),
>> tkey->FindObject(), tfolder->GetListOfFolders(), etc
>>
>> So what's thread safe and what is not? (Plus remember that the end user
>> can create and destroy
>> objects all the time at any time - my thread has to be protected against
>> race
>> conditions on access to destroyed objects (i.e. th1=FindObject(); /*
>> object is deleted by user in
>> the main thread */; th1->Reset(); /* boom!!! */).
> >
> Typically I would protect FindObject() in the case another threads could
> delete the found object in the meanwhile. If no such danger, of course no
> need to lock.
>>
>> For the curious, the actual code is here:
>> http://ladd00.triumf.ca/viewvc/rootana/trunk/libNetDirectory/netDirectoryServer.cxx?view=markup
>> it uses a mickey-mouse locking scheme in RootLock.cxx that does not use
>> TThread::Lock (probably
>> did not exist when my code was written).
>>
>>
>
> Cheers, Fons.
>
>
> --
> Org: CERN, European Laboratory for Particle Physics.
> Mail: 1211 Geneve 23, Switzerland
> E-Mail: Fons.Rademakers_at_cern.ch Phone: +41 22 7679248
> WWW: http://fons.rademakers.org Fax: +41 22 7669640
>
Received on Wed Feb 02 2011 - 17:21:22 CET