Thanks for your response,
Let me describe how I intend to use cint:
I work for TTI-Telecom (.com). We are working on a C++
framework for building applications. Some of these applications
will be concerned with non-stop retreiving, processing,
and storing large amounts of data such as telephony billing
data from switches, etc. We want to make the data processing
'scriptable' - i.e., the 'recipe' that describes how to process
or 'reformat' the data will be a C++ script, which will provide
great flexibility to the system. Also, interaction protocols
with remote machines (login scripts, issuing remote commands,
etc) can be described by such a script.
We want to provide this scripting capability as part of our
C++ framework. We need to call some C++ interpreter from
compiled code (i.e., non-interactively), and tell it to *run*
some script, or occasionally to step through a script in order
to debug it.
We will typically have multiple threads in our framework, and
each thread can, at any time, 'invoke' a script interpreter
and tell it to run some script. This is our use case for
thread safety.
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?
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