On Thu, May 3, 2018 at 4:55 AM, Rony G. Flatscher <rony.flatsc...@wu.ac.at>
wrote:
>
>
> 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.
>
If you are worried about data integrity, then don't hand out references to
object variables. You can always use a local variable and then do the
assignment on your own terms.
>
> 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).
>
Until the method opts to go unguarded or chooses to use its access to the
variable scope to give out a reference. That code that has access to the
variable is in control of whether to use the reference or not. No other
code can reach back into that method to grab a reference, it is permission
that must be granted.
>
> 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
>
>
> This is a rabbit hole I am not going to jump into. It require a complete
redesign of how variables work with some fairly major performance
considerations, as well as introducing entirely new opportunities for dead
locks. If you don't want object variables to be changed via this mechanism,
the DON'T USE THEM. Use a local variable instead and there are no data
integrity issues. You already have complete control on how this works
without having to invent elaborate mechanisms that probably won't provide
the levels of protection you want. And, quite frankly, like with what you
were trying to do with Address With, you are probably the only person who
would try to use references this way. The rest of the world will be using
it for the purpose of returning more than one value from a routine or
method.
Rick
Rick
> ------------------------------------------------------------
> ------------------
> 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
>
>
------------------------------------------------------------------------------
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
