> We just need to invoke multiple interpreters, each in a
> different thread, and we need them to work independantly without
> interfering with each other. We do *not* need multiple threads
> accessing the *same* instance of the interpreter. In other
> words, CINT doesn't need to be aware of multiple threads,
> and to service all of them correctly. All we need is to run
> multiple *independent* cint's, in different threads, that do
> not interact with each other. I am not sure, but maybe this
> makes the thread safety issue easier?
>
Hello Christoph,
I do not think your case makes "the thread safety issue easier"
CINT relies on some static variables those will be shared by
all threads and you will face the C++ scope problem as well.
On another hand if your "CINT" threads have nothing to share why
they are "threads"?
They can be just independent "processes" and it solves all your
problems.
Very likely you will still need creating some very simple "CINT-aware" thread
per your "customer". Each thread is to launch / terminate a separate "CINT"
process and send an ACSII text message with "C++ statement" and
retrieve the results.
What is wrong with this schema ?
Valery
> Anyway, I have started to work on using CINT for an initial
> version that will be single threaded. I like CINT, and it will
> help us to quickly get an initial working version.
> Later we will need to look how to tackle thread safety.
>
> Our options for that are (sorted by my personal preference)
>
> (1) Find a way to use CINT in multithread situation
>
> (2) Use another existing interpreter.
> (my company will consider commercial/closed source systems
> as well..) You mentioned other interpreter systems,
> could you point me to some of them with some links?
>
> (3) Write a custom interpreter for our needs, which will
> support only a *very* limited subset of C++, just to match
> our needs.
>
> regards,
> Christoph
>
>
>
>
> on Nov 8 Masaharu Goto wrote:
>
> > Hello Christoph,
> >
> > About multi-thread and Cint,
> >
> > It is quite difficult to make Cint thread safe.
> > Of course, the simplest answer is that there are static
> > variables. But in reality, Cint use-case has fundamental
> > difficulty. Cint allows users to dynamically load/unload
> > macros and source files. Symbols are managed in stack-wise
> > manner. This can be guaranteed because cint has only one
> > thread. If I need to allow multi-threading, dynamic unloading
> > of the macros and source files must be limited. This must be
> > a major use-case for ROOT. If you look at other multi-thread
> > systems, they mostly run on a statically configured program.
> > Same limitation has to be applied. This means, you can not
> > load/unload macros and source files. I can explain other problems
> > too, but the bottom line is that , at this moment, it is not
> > realistic to make cint thread-safe.
> >
> > I recommend you to look at shared memory and fork solution. If
> > I remember correctly, Linux pthread is emulated by those
> > techniques. So, the overhead should be the same. I once benchmarked
> > shared memory performance. Shared memory performs as fast as
> > normal memory when you do memory access. If you want to synchronize
> > semaphore takes time, but it should be the same for multi-thread.
> > So, I do not see any performance degradation from multi-thread
> > unless operating system does bad job of implementing shared memory.
> > There are examples in demo/ipc and demo/mthread directories of pure cint
> > distribution.
> >
> > I will also think about providing easy-to-use thread emulation
> > using fork and shared memory. Will you teach me a little more detail
> > about your application so that I can understand your basic needs about
> > multi-threading?
> >
> > Thank you
> > Masaharu Goto
> >
> >
> > >
> > >Hi,
> > >
> > >What would it take to make CINT thread safe?
> > >
> > >I would like to use CINT in a data processing system, where multiple data
> > >streams are processed by multiple C++ 'scripts'. (macros in root
> > >terminology :-). So we need multiple CINT's executing simultaneously.
> > >
> > >The option of running CINT's in multiple processes would affect
> > >performance because we have large amounts of data, and moving it between
> > >processes is expensive.
> > >
> > >Compiling the scripts with a native compiler is a good solution,
> > >but for some reason we can't do that in all cases.
> > >(well the reasons are basically convenience for the user, and some
> > >concern that compiling scripts at run time by the user will have technical
> > >limitations / problems / platform independence issues etc. This may not
> > >be that much of a problem though. another reason is that scripts can be
> > >debugged with the interpreter, and compiled code can't)
> > >
> > >So ideally we would like to run multiple independent CINT threads,
> > >all in the same process! I know this is not currently possible.
> > >my question, then is: (all right: are)
> > >Would it be hard to add thread safety to CINT? (Maybe I can help)
> > >Why, actually, is CINT tread unsafe?
> > >(I have been told that if static variables are the only problem they can
> > >be replaced quite transparently with a class wrapper that checks for the
> > >thread ID whenever it is accessed.)
> > >
> > >regards,
> > >Christoph
> >
>
>
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:37 MET