The thread in ooRexx is a cooperative threading model with only one thread of execution permitted at any one time. The active thread holds the global interpreter lock and other threads wait in a queue until the active thread relinquished control. It would take a considerable effort to make the entire interpreter thread safe enough to allow true multi-threaded activity.
Rick On Sun, Dec 6, 2009 at 7:34 PM, Jean-Louis Faucher <[email protected]> wrote: > After watching http://blip.tv/file/2232410 (Python GIL), > and reading http://www.igvita.com/2008/11/13/concurrency-is-a-myth-in-ruby > I was curious to know how behaves ooRexx. > > I wrote a small script to test the impact of using 0 to 4 tasks, in addition > to the main task. > See attached file count_par.rex > > Test cases (100000 iterations): > rexx count_par.rex 100000 0 --> main thread + 0 thread > rexx count_par.rex 100000 1 --> main thread + 1 thread > ... > rexx count_par.rex 100000 4 --> main thread + 4 threads (main does > nothing) > > Tested on > WinXP, Intel Core Duo CPU T2400 @ 1.83GHz 2Gb (2 CPU in task manager) > Win2000, Intel Xeon CPU 5150 @ 2.66GHz 3Gb (4 CPU in task manager) > Didn't test under Linux... > > Conclusion : The duration increases when the number of threads increases > (tested with trunk release configuration). > Normally, should decrease, but maybe the test cases or my system > configuration are not good. > > To have an idea of what happens in the interpreter, I inserted > OutputDebugString in SysSemaphore.hpp, and passed additional parameters to > know who uses the mutexes and the semaphores. > An example of output : log-000010.txt for test case : rexx count_par.rex 0 0 > > See stats.ods for a summary of the number of calls. > The counters give the number of occurrence in the log file. Most of the > time, their value must be divided by 2 to get the real number (because > listed twice : before and after the access to the mutex or the semaphore), > or even divided by 3 for RexxActivity::runThread > The name of the semaphore variables is null because > RexxActivity::RexxActivity calls this->clearObject(); which overwrites the > names assigned by the semaphore constructor. > > Some observations : > When only the main thread is running, there is no semaphore and the number > of release/request of Interpreter::resourceLock.release is constant. > As soon as an additional thread is created, then the > Interpreter::resourceLock is highly sollicited by > ActivityManager::addWaitingActivity > > More work needed to understand all that... Iet me know if I'm wrong > somewhere. > > Jean-Louis > > > ------------------------------------------------------------------------------ > Join us December 9, 2009 for the Red Hat Virtual Experience, > a free event focused on virtualization and cloud computing. > Attend in-depth sessions from your desk. Your couch. Anywhere. > http://p.sf.net/sfu/redhat-sfdev2dev > _______________________________________________ > Oorexx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
