Multithreading is a very powerful feature of ooRexx and very versatile!
For the following two scenarios I would have a question ad how to determine in native code whether a
method routine is currently executing guarded or unguarded and whether it is currently blocked
(waiting on a lock and if so which one, the runSem or the guardSem):
* # 1: unguarded methods can run concurrently to any other methods in the same
scope, no matter
whether they are guarded or unguarded
o however, it is possible in an unguarded method to issue a "GUARD ON"
which makes it guarded
during execution, i.e. it can only run if it gains the runLock: how can
one determine
whether an unguarded method has the runLock or needs to wait for it? And
how can one
determine whether such a method turned unguarded again by issuing a "GUARD
OFF" later?
* # 2: guarded methods in the same scope can run only serialized one after the
other
o however, it is possible in a guarded method to issue a "GUARD OFF" which
makes it unguarded
during execution, i.e. it can run from then on concurrently to any other
method of the same
scope: how can one determine whether a guarded method is currently
running unguarded in
native code? And how can one determine whether such a method turned
guarded again by issuing
a "GUARD ON" later?
While experimenting with the methods from the native classes Activity and RexxActivation I was not
able to find out whether a method routine is executing at the time of inspection guarded or
unguarded (it is possible to find out how the method got defined originally with RexxActivation's
isGuarded()).
---
So the question is: how can one find out whether the currently traced statement from a method
routine in the activity will be blocked such that one can indicate this in the multithreaded trace
prefix?
The location and time to report that would be in "void Activity::traceOutput(RexxActivation
*activation, RexxString *line) {...}".
Can this be done?
---
If it was possible to display the blocking state it would augment the utility of the multithreaded
tracing prefix considerably, helping the ooRexx programmers to debug MT programs even more.
---rony
P.S.: If guarded methods do not get changed to unguarded while invoked it would be easy to determine
the blocking state: if they do not hold the object variable pool's lock (Activation's
isObjectScopeLocked()), then they would have to wait until they gain it and one can supply a 'B' for
hinting it being currently blocked (but this is dependent on whether the method routine is currently
in the guarded state or not).
P.P.S.: Working on a solution that meets Rick's idea of making this much more flexible by allowing
the Rexx programmers to create that prefix tailored to their own needs. The default MT trace prefix
would carry all information that needs to be available for very complex multi interpreter instance,
multithreaded ooRexx programs.
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
