AW: [ROOT] TThread: What can be done in a thread?

From: Adamczewski Dr. Joern (J.Adamczewski@gsi.de)
Date: Fri Oct 26 2001 - 17:41:22 MEST


Dear Marc,

just a few comments to your questions:

> Why should the TApplication "know" about sockets and their 
> creation location
> (threads or main process)? On basis of the operating system, this is
> completely transparent to any application. It's just file 
> descriptors. If it
> makes really a difference, then it is the problem of the OS.
What I meant is the fact that there is a list of TSockets in the
TROOT class; in the ctor of the TServerSocket any new TSocket is
added to this list, and on termination of root, these sockets
should be closed by the system. Of course this list is
not inherently threadsafe, i.e. if two or more threads access this
list at the same time, the resulting entries might not be
predictable...


> A FIN_WAIT state on a TCP connection may by caused by several 
> reasons (e. g.
> some problems in closing the socket in the right order: 
> server first/second,
> client second/first, still some valid data on the descriptor, 
> ...). The OS
> simply does e. g. not know if there is still a valid 
> end-point on one of the
> sides.
I know that. But this was _not_ the problem I was describing.
When the TServerSocket was created in the thread function,
the connections were established, the communication was working.
On program termination, however, the tcp sockets created in such a way
stayed in the FIN_WAIT state, independent of the order of closing
them. I made a number of tests on that in the beginning of this year,
with the conclusion that the TSockets were closed properly when
created in the scope of the main root application loop
(main program, TTimer::Notify), but did not close when the TServerSocket
was created in a threaded function.
This behaviour might have changed in the most recent root versions,
but this was my observation then. 
As a consequence, I submit all creation of root sockets to a 
service TTimer now, which delivers back the TSocket pointers to
the communication thread. 

> 
> Another point: why should the TMonitor::Select() work not 
> properly? It's
> just the same remark as above: it's just file descriptors. 
The TMonitor::Select() invokes gSystem->InnerLoop(),
which calls TUnixSystem::DispatchOneEvent().
Here _many_ of the root internal lists are iterated and might be modified.
As stated above, all these lists are _not_ threadsafe, i.e.
there is no internal TThread::Lock() around these list operations!
If TMonitor::Select() is called from more than one thread, you cannot
predict what happens to these lists, which take care for the root internal
file descriptors, signal handlers, etc
(I hope I understood the system right; anybody of the root developers
correct me please, if I missed something important...)


> And last but not
> least: locking everything around a Streamer and any object 
> instatiation is a
> really hard performance killer. In our Client/Server 
> Monitoring Application
> we rely heavily on all the features above mentioned, and I 
> don't see anymore
> the limitations you mentioned. 
It depends on the application you are doing. In our tests
it turned out that everything worked fine, until we
tried to process a _real_ event analysis in a main thread,
while the transport threads were streaming some histograms
at the same time. This crashed unpredictably.
When locking the streaming against the eventloop, it was stable.

So, you might decide to drop the locking if you are sure that
the potential thread conflict does not occur very often,
for performance reasons, OK.
For an online/offline analysis framework that shall run
stable for days or weeks, however, I would not dare so.

I'm looking forward to exchange some threading experience
again ;-)

Best regards,

	Joern


/////////////////////////////////////////////////////////////////////
// Dr. J"orn Adamczewski                    (J.Adamczewski@gsi.de) //
// GO4 project team                         Tel: +49-06159-71-2554 //
// Datenverarbeitung & ExperimentElektronik FAX: +49-06159-71-2986 //
// Ges. f. SchwerIonenforschung, Planckstr.1,  D-64291 Darmstadt   //



This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:51:04 MET