On 05.09.2024 12:01, Rony G. Flatscher wrote:
In order to communicate in as few words as possible, but still conceptually understandable how
multithreading in ooRexx works, this is the current state:
* ooRexx, Kicking Off Multithreading
o Using the reply keyword instruction in a method
+ Returns to caller (optionally with a return value)
+ Remaining instructions get dispatched on a new thread
o Sending messages asynchronously
+ Message object's start method
+ Root class Object's start method (returns the message object)
o Native code invoking ooRexx scripts from a different thread
+ E.g. callbacks from GUI event handlers to ooRexx
* Multithreading Rules, 1
o All attributes and methods of a class share the same (class) "scope"
+ Instances of a class maintain an attribute pool (object
variable)
+ All methods of the same (class) scope can directly access the
instance's attribute
pool
+ By default ooRexx will define methods to be guarded
# Only one guarded method can access the instance's attribute
pool, after
successfully acquiring its guard (scope) lock which
increases the guard lock count
# A guarded method owning the guard lock may invoke
additional methods in its
scope causing an increase of the guard lock count (upon
return the count gets
reduced)
+ Messages from different threads can only invoke a guarded
method, if the guard
lock count is zero, otherwise the invocation must wait for it
to become zero
# This ensures that guarded methods can not mistakingly
update the attribute
pool concurrently
* Multithreading Rules, 2
o Unguarded methods can always be invoked
+ Unguarded methods can unconditionally interact with the
attribute pool
o The GUARD ON/GUARD OFF keyword statements
+ Available in methods only
+ GUARD keyword instructions get carried out only, if the guard
(scope) lock is owned
+ GUARD ON changes an unguarded method to a guarded one (no
effect for guarded methods)
# If successful, the guard (scope) lock gets acquired and its
guard lock counter
gets increased
# If unsuccessful, then the instruction must wait until the
guard (scope) lock
can be acquired
+ GUARD OFF changes a guarded method to an unguarded one (no
effect for unguarded
methods)
# The guard (scope) lock gets released and the guard (scope)
lock counter decreased
+ Optional WHEN condition (referencing attributes used as control
variables) on
GUARD ON|OFF
# GUARD gets carried out only if the WHEN condition turns true
# If false, the WHEN condition gets only re-evaluated, if its
referenced
attribute values change!
Here a slightly improved version of # 2:
* Unguarded methods can always be invoked
o Unguarded methods can unconditionally interact with the attribute
pool
* The GUARD ON/GUARD OFF keyword statements
o Available in methods only
o GUARD keyword instructions get carried out only, if the guard
(scope) lock is owned
+ If acquiring the guard (scope) lock successfully, the guard lock
counter gets
increased as well
+ Optional WHEN condition (referencing attributes used as control
variables) on GUARD
ON|OFF
# GUARD gets carried out only if the WHEN condition evaluates
to true
# If evaluating to false, then
* the guard (scope) lock counter gets decreased and the
guard (scope) lock
released
* the WHEN condition gets only re-evaluated, if its
referenced attribute
values change!
o GUARD ON changes an unguarded method to a guarded one (no effect for
guarded methods)
o GUARD OFF changes a guarded method to an unguarded one (no effect
for unguarded methods)
+ The guard (scope) lock counter gets decreased and the guard
(scope) lock released
---rony_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
