RE:Re: RE:Re: [ROOT] CINT thread safety hac

From: Masaharu Goto (MXJ02154@nifty.ne.jp)
Date: Tue May 22 2001 - 14:38:33 MEST


Hello Christoph,

I tried Cint multithreading with your scheme on Linux. It basically seems
to work, but has some problem. Let me explain what I've found.

# When it works
   Cint multithreading works with multiple shared library object if no
  further shared libraries are loaded by cint. This is illustrated as
  follows.

         main program ------> libcint1.so
                      ------> libcint2.so
                      ------> libcint3.so
                        .         .

   Static variables in libcint.so are independently maintained and 
  multithreading works as expected.

# When it does not work
   However, if further shared library is loaded by cint, it has problem
  resolving symbols in libcint. For example,

    main program  ------> libcint1.so -------> otherlib.so (G__cpp_XXX.C)
                                     <--------
                                  tries to find functions
                                  in libcint1.so, but it fails

  suppose otherlib.so is created by makecint and it contains G__cpp_XXX.C.
  Code in G__cpp_XXX.C uses functions in libcint.so. otherlib.so is loaded,
  for example, by '#include "otherlib.so"' At dictionary initialization, 
  it fails to find symbols in libcint.so. Even if it finds a symbol, it 
  is not guaranteed that the symbol comes from right libcint?.so, because
  you have multiple of them.  Someway, this causes segmentation violation.


I can think of a way to solve this problem.  However, we will lose
compatibility from existing version which is not tribial. 
Let me think for a while.

Thank you
Masaharu Goto


>Hello Masaharu,
>
>Actually the idea was of a collegue of mine, here in TTI.  On the one hand, w
e
>know it a 'not very elegant' (to say the least) workaround, but on the other
>hand - I can't think of a reason why it shouldn't work.  We need to use this 
on
>most platforms, and I already tried this on Linux/gcc-3.0-snapshot,
>Solaris/CC5, and NT4/msvc. On Solaris it already seems to work quite well.
>
>
>I read somewhere in the CINT documentation that you recommend people to
>'register' when they are using cint.
>So I would like to register myself and my employer as a cint user :)
>
>I am using cint as part of a larger C++ framework that our company uses as a
>basis to develop our applications. TTI-Telecom is a software company, with +-
>500 employees. We are selling solutions (servers + software) to telephony
>companies all over the world. We need 'scripting capabilities' in our
>framework, and we intend to use cint for this. I am a programmer working at
>TTI, and my job is currently to implement the scripting capabilities of our
>framework.
>
>Thanks a lot :-)
>Yours,
>
>Christoph Bugel
>TTI Telecom
>www.tti-telecom.com
>
>
>
>On Thu 2001-05-10, Masaharu Goto wrote:
>> Hello Christoph,
>> 
>> This is a very interesting idea. As far as I know,
>> nobody has tried it.   Whether or not this works depends
>> on a shared library symbol resolution scheme in your
>> operating system.  If the operating system always resolves
>> symbols within own shared library, it works. However,
>> if symbols are resolved among multiple libraries, this won't
>> work. I have a feeling that this works for Windows and
>> IBM AIX, but not for most of the other platforms.  
>> 
>> I'll try this myself as soon as I can find my time.
>> 
>> Will you teach me which platform are you using?
>> 
>> 
>> Thank you
>> Masaharu Goto
>> 
>> 
>> >Date: Thu, 10 May 2001 13:24:46 +0300
>> >From: Christoph Bugel <chris@uxsrvc.tti-telecom.com>
>> >To: Valeri Fine <fine@bnl.gov>
>> >Cc: roottalk@pcroot.cern.ch, MXJ02154@nifty.ne.jp
>> >Subject: Re: [ROOT] CINT thread safety hack?
>> >
>> >Hi Valeri,
>> >
>> >Actually I don't use ROOT at all! (I installed it, out of curiosity of
>> >course, and was very impressed) but I 'just' need a C++ interpreter, and
>> >this mailing list is for CINT as well. (I think (?)).  My shared library
>> >doesn't contain ROOT. I just download the most recent cintX.Y.Z.tar.gz
>> >every now and then from root.cern.ch, and compile it. (and play around
>> >with the Makefiles as needed to create a shared library).  You mentioned
>> >the 'CINT Thread' - with other threads sending messages to it. I don't
>> >need other thread talking with the CINT thread.  But on the other hand,
>> >I need more than one 'CINT thread'!!  Each CINT is totally independent,
>> >and runs a totally different C++ function. You are right to ask - why
>> >don't I do it in different processes, when there is nothing to share
>> >anyway. The answer is that this code has to fit into an existing
>> >framework with a very object oriented && multithreaded architecture, it
>> >is just a given fact that I have to comply with..
>> >
>> >I still didn't run it under gdb, admittedly.
>> >
>> >I understand that cint does dynamic loading and unloading of dlls at
>> >runtime. But since I don't use those features (I think I don't --  I
>> >don't use any libraries such as iostream, STL, etc, and I dont do any
>> >#pragma compile or any other #pragma, I just run a C++ function from a
>> >file -- nothing 'dynamic') I hoped I could succeed to run simultaneous
>> >CINT threads without a problem, provided I could isolate them from each
>> >other by loading them into different memory locations (as described
>> >below) -- effectively multiplexing their global variables. I know this
>> >has been discussed before, but my boss wanted to try out anyway. After
>> >all, in theory it should (probably) work. Actually, it already works,
>> >some times.. I managed to load two 'instances' of cint, each running a
>> >different program, only right now this succeeds sometimes and crashes
>> >sometimes :(
>> >
>> >Christoph
>> >
>> >
>> >
>> >On Wed 2001-05-09, Valeri Fine wrote:
>> >
>> >> Hi, Chrisoph
>> >> 
>> >> >
>> >> > I am currently trying out an *ugly* workaround to run multiple cint's
>> >> > in multiple threads. They don't need to share anything between each
>> >> > other. Each cint thread will just load a some file and execute a few C
>> >> > functions from it.  If anyone can point out why the following method
>> >> > will break - please do!
>> >> 
>> >>   The question is which thread is responsible for the dictionaries of al
l
>> >>   ROOT classes?
>> >> 
>> >>   Did you assume each your share library will include the entire ROOT ?
>> >>   Then why do you need all of this, it is much simpler just to run the
>> >> separate
>> >>   processes.
>> >> 
>> >>  On another hand the Windows version of ROOT is 4 threads application by
>> >> now.
>> >>  One of them drives "CINT", others are to sent mesages to the "Cint" 
thread
>> .
>> >>  Somehow it works,
>> >> 
>> >> 
>> >> > The workaroud is as following: I compiled cint into a shared library
>> >> > (.so). My process copies this cint.so into a few identical copies with
>> >> > *different* names -- one for each thread. for example cint.1.so,
>> >> > cint.2.so, cint.3.so, etc.  Then, each thread does a dlopen on its own
>> >> > copy of cint and looks up (dlsym) the symbols it needs (like
>> >> > G__init_cint, G__loadfile, G__exec_text, etc). Because the dlls have
>> >> > different names, the code will be entirely loaded each time, so
>> >> > cint.1.so and cint.2.so are each loaded into another memory location,
>> >> > and all variables used by cint are multiplexed - even global and stati
c
>> >> > ones.
>> >> 
>> >>   If variables are to be multiplexed then why do you need the threads.
>> >>   I am guessing you do want your threads share information via common
>> >>   memory.
>> >> 
>> >> > This method worked for some simple tests (without cint). This method
>> >> > does not protect shared resources such as files, but then I think sinc
e
>> >> > cint generates random temporary filenames two thread won't use the sam
e
>> >> > filename anyway.  It almost works for me already, only I just got a
>> >> > segfault, and I wondered if I forgot something. (Usually these
>> >> > segfaults are my own fault) did I miss something important?
>> >> 
>> >>  Did you try this under debugger. What did it say ?
>> >> 
>> >>     Valeri
>> >
>> >-- 
>
>-- 



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