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:36 MET