On 02.05.2018 17:12, Rick McGuire wrote:
> The question would be whether this should be just documented or whether
> access via variable
> reference to attributes should be blocked if a concurrently executing
> method of that class is
> in guard mode (maybe only if the attribute in question is exposed by it).
>
>
> That is not how guards work, your statement about blocking access doesn't
> really make much sense.
> What is really going on here is more akin to what procedure expose does, but
> it works across
> external (and even native) calls and can also reach across threads.
The point I have tried to make is that in concurrency situations the data
integrity is put at risk,
a classic problem in multithreaded executing systems.
The guard mechanism of methods makes sure that no data integrity issues can
occur with the
attributes ("object variables") among methods of the same class/scope as by
default only one such
guarded method is able to execute and access object variables. The programmer
may lift that
restriction by using the subkeyword "unguarded" on the method directive or
using "guard off" and
"guard on" keyword statements to allow for even fine-granular control of
execution with the risk of
data integrity that she has to keep in mind and avoid. If I am not mistaken,
then a variable
reference to an attribute (object variable) can only be handed out by a method
that has EXPOSE
access to the attribute, so the default shelter against data integrity problems
remains in effect
(Rexx code cannot access object variables outside of methods).
What would be nice though would be a mechanism that allows for guarding read
and write access to
variable references such that data integrity problems can be avoided in use
cases where concurrent
access via the variable reference is to be expected. Maybe something like a
lock/guard on the
variable reference that can be set and which will get released either by the
program or if the
variable reference goes out of scope because of returning from a routine by the
interpreter. This
way one could use such a lock/guard to create a critical section for accessing
variable references
in concurrency situations, something like:
call change >someVar, newValue
...
::routine change
use arg varRef, newValue
varRef~lock=.true -- blocks, if lock already granted to someone else
say "varRef~value:" varRef~value
varRef~value=newValue
varRef~lock=.false -- clear lock, allow others to lock
return
---rony
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
