Re: Is ROOT threadsafe?

From: Fons Rademakers <Fons.Rademakers_at_cern.ch>
Date: Wed, 2 Feb 2011 17:30:04 +0100


Hi Victor,

  in ROOT X11 via TCanvas is kind of thread safe due to your forwarding code, but pure X11 from multiple threads still can cause problems, even with X11 thread support enabled (which of course we have).

Cheers, Fons.

On 02/02/2011 17:21, Victor Perev wrote:
> 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
>>
>

-- 
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:30:09 CET

This archive was generated by hypermail 2.2.0 : Wed Feb 02 2011 - 23:50:01 CET