In complement of the struct, this is how the infos are collected for each trace
line:
void GetConcurrencyInfos(Activity *activity, RexxActivation *activation,
ConcurrencyInfos &infos)
{
InterpreterInstance *interpreter = (activity ? activity->getInstance() :
NULL);
VariableDictionary *variableDictionary = (activation ?
activation->getVariableDictionary() : NULL);
/* R */ infos.interpreter = interpreter ? interpreter->getIdntfr() : 0;
/* T */ infos.activity = activity ? activity->getIdntfr() : 0;
/* A */ infos.activation = activation ? activation->getIdntfr() : 0;
/* V */ infos.variableDictionary = variableDictionary ?
variableDictionary->getIdntfr() : 0;
/* n */ infos.reserveCount = activation ? activation-> getReserveCount() :
0;
/* * */ infos.lock = (activation && activation->isObjectScopeLocked()) ?
'*' : ' ';
}
> On 11 Feb 2023, at 18:32, Jean Louis Faucher <jfaucher...@gmail.com> wrote:
>
> A quick feedback about point 1:
> The A column is in fact the activation identifier (RexxActivation).
> It’s used to know which method/routine is executing the current line.
> The name of this method/routine can be found by looking back in the trace the
> first >I> for the current T.
>
> In rexxref, “activation” is not used.
> I think the good term is “invocation”, as in "An activity contains a stack of
> invocations… An invocation is activated when an executable unit is invoked
> and removed (popped) when execution completes. "
>
>
> This is the displayed informations
> struct ConcurrencyInfos
> {
> uint32_t interpreter;
> uint32_t activity; —> display a counter related to the system
> tread identifier, not the activity identifier
> uint32_t activation;
> uint32_t variableDictionary;
> unsigned short reserveCount;
> char lock;
> };
>
>> On 11 Feb 2023, at 18:16, Rick McGuire <object.r...@gmail.com
>> <mailto:object.r...@gmail.com>> wrote:
>>
>> Some comments:
>>
>> 1) the T and A columns are a bit redundant. We really only need a single
>> identifier for the thread, having two is just extra clutter.
>> 2) The term activity is introduced here without explanation. It doesn't
>> really appear any other place in the documentation and is really more of an
>> internal concept than part of the language. If it is used here, then this
>> needs to be used consistently in all other places that concurrency is
>> discussed.
>> 3) The variable pool term is a bit misleading. The thing that gets locked is
>> the object's variable pool for a particular scope, not all of the variables
>> for the object. For example, two different threads might have the GUARD lock
>> on the same object at different scope levels. Knowing the scope would be a
>> very useful piece of information.
>> 4) I don't like the use of the term "lock" here. At least refer to them as a
>> GUARD lock, since that is the concept that is used in other places.
>> 5) I still don't like the M prefix. I think things would just be simpler if
>> multi-thread mode is used any time there are multiple active threads.
>>
>> Rick
>>
>> On Sat, Feb 11, 2023 at 12:02 PM Rony G. Flatscher <rony.flatsc...@wu.ac.at
>> <mailto:rony.flatsc...@wu.ac.at>> wrote:
>> Ad documentation: here a draft, meant for rexxref.pdf, chapter "12.
>> Concurrency", suggesting of adding a section at the end (activity, variable
>> pool, locks already explained in that chapter):
>>
>> --------------
>>
>> 12.5 Tracing Concurrent Execution
>>
>> Each invoked routine and method routine will execute on a proper activity.
>> If a
>> method runs for different objects each such invocation will execute on a
>> proper
>> activity. Activities may run on different threads if sending messages
>> concurrently or using the reply keyword instruction.
>>
>> Upon entry of a method routine access to the variable pool of the object (its
>> object variables, attributes) gets secured by reserving exclusive access by
>> default. If a concurrent message to the same object gets sent from a
>> concurrently executing part of the program, then the method routine attempts
>> to
>> get the lock on the variable pool and will be blocked as long as the the
>> owning
>> method routine for that object does not release it, either by returning from
>> the method invocation or by issuing "guard off" in its routine.
>>
>> If a method routine's activity owns the variable pool lock it may invoke
>> other
>> method routines by sending the message to "self" without getting blocked.
>>
>> In order to help understand and debug concurrently executing programs the
>> TRACE
>> keyword instruction and the TRACE() built-in function allow for supplying
>> additional trace output information by adding five columns to the begin of
>> the
>> trace output:
>>
>> - the Rexx instance column: the letter 'R' plus a unique number denoting a
>> proper Rexx interpreter instance. This is a counter that starts out with 1.
>> If ooRexx gets instrumentated by applications it may be possible that
>> different
>> Rexx programs may execute concurrently on different Rexx interpreter
>> instances
>> (cf. rexxapi.pdf, 1.1.1 RexxCreateInterpreter).
>>
>> - the operating system thread column: the letter 'T' plus a unique number per
>> operating system thread in the process. This is a counter that starts out
>> with
>> 1.
>>
>> - the activity column: the letter 'A' plus a unique number per activity
>> currently used for executing a specific routine or method routine for a
>> specific
>> object. This is a counter that starts out with 1. Please note: upon return
>> from a routine its activity will get returned to the interpreter and will get
>> reused for future routine or method routine invocations.
>>
>> - the variable pool column: the letter 'V' plus a unique number which
>> indicates
>> the attributes (object variables) of a specific object for which a method
>> routine gets executed on an activity. This is a counter that starts out
>> with 1.
>>
>> - the lock column: empty, if no lock issued yet (maybe blocked), or a
>> number that indicates how many locks there are for the variable pool. If
>> a number is shown, then a trailing asterisk (*) indicates which activity
>> owns the lock, i.e. the object's variable pool. If the trailing asterisk
>> is missing, than that activity is currently blocked.
>>
>> --------------------------------------- trace example 1 (begin)
>> -------------------
>> Tracing Example 1: Asynchroneously sending the same message to two
>> different objects of the same class (no blocking takes place)
>>
>>
>> /* Example of using a message object */
>> object1 = .example~new
>> object2 = .example~new
>> a = object1~start("REPEAT",3,"Object 1 running")
>> b = object2~start("REPEAT",3,"Object 2 running")
>> say "a:" a~result
>> say "b:" b~result
>> say "Main ended."
>>
>> ::class example
>> ::method repeat
>> use arg reps,msg
>> do reps
>> say msg
>> end
>> return "Repeated" msg"," reps "times."
>>
>> ::options trace a
>>
>> Trace output:
>>
>>
>> R1 T1 A1 2 *-* object1 = .example~new
>> R1 T1 A1 3 *-* object2 = .example~new
>> R1 T1 A1 4 *-* a =
>> object1~start("REPEAT",3,"Object 1 running")
>> R1 T1 A1 5 *-* b =
>> object2~start("REPEAT",3,"Object 2 running")
>> R1 T1 A1 6 *-* say "a:" a~result
>> R1 T2 A2 V1 >I> Method "REPEAT" with scope
>> "EXAMPLE" in package "G:\oorexx.tmp\concurrencyTrace\example_12_3.rex".
>> R1 T2 A2 V1 1* 12 *-* use arg reps,msg
>> R1 T3 A3 V2 >I> Method "REPEAT" with scope
>> "EXAMPLE" in package "G:\oorexx.tmp\concurrencyTrace\example_12_3.rex".
>> R1 T2 A2 V1 1* 13 *-* do reps
>> R1 T3 A3 V2 1* 12 *-* use arg reps,msg
>> R1 T2 A2 V1 1* 14 *-* say msg
>> Object 2 running
>> R1 T3 A3 V2 1* 13 *-* do reps
>> R1 T2 A2 V1 1* 15 *-* end
>> R1 T3 A3 V2 1* 14 *-* say msg
>> Object 1 running
>> R1 T2 A2 V1 1* 13 *-* do reps
>> R1 T3 A3 V2 1* 15 *-* end
>> R1 T2 A2 V1 1* 14 *-* say msg
>> Object 2 running
>> R1 T3 A3 V2 1* 13 *-* do reps
>> R1 T2 A2 V1 1* 15 *-* end
>> R1 T3 A3 V2 1* 14 *-* say msg
>> Object 1 running
>> R1 T2 A2 V1 1* 13 *-* do reps
>> R1 T3 A3 V2 1* 15 *-* end
>> R1 T2 A2 V1 1* 14 *-* say msg
>> Object 2 running
>> R1 T3 A3 V2 1* 13 *-* do reps
>> R1 T2 A2 V1 1* 15 *-* end
>> R1 T3 A3 V2 1* 14 *-* say msg
>> Object 1 running
>> R1 T2 A2 V1 1* 13 *-* do reps
>> R1 T3 A3 V2 1* 15 *-* end
>> R1 T2 A2 V1 1* 16 *-* return "Repeated" msg"," reps
>> "times."
>> R1 T3 A3 V2 1* 13 *-* do reps
>> R1 T3 A3 V2 1* 16 *-* return "Repeated" msg"," reps
>> "times."
>> a: Repeated Object 1 running, 3 times.
>> R1 T1 A1 7 *-* say "b:" b~result
>> b: Repeated Object 2 running, 3 times.
>> R1 T1 A1 8 *-* say "Main ended."
>> Main ended.
>>
>> --------------------------------------- trace example 1 (end)
>> -------------------
>>
>>
>>
>> --------------------------------------- trace example 2 (begin)
>> -------------------
>>
>> Tracing Example 2: Asynchroneously sending the same message to the same
>> object of the same class (blocking takes place)
>>
>> /* Example of methods with the same scope not running concurrently*/
>> object1 = .example~new
>>
>> a = object1~start("REPEAT",3,"Object 1 running call 1")
>> b = object1~start("REPEAT",3,"Object 1 running call 2")
>> say "a:" a~result
>> say "b:" b~result
>> say "Main ended." /* concurrently. */
>>
>> ::class example
>> ::method repeat
>> use arg reps,msg
>> do reps
>> say msg
>> end
>> return "Repeated" msg"," reps "times."
>>
>> ::options trace a
>>
>> Trace output:
>>
>> R1 T1 A1 2 *-* object1 = .example~new
>> R1 T1 A1 4 *-* a =
>> object1~start("REPEAT",3,"Object 1 running call 1")
>> R1 T1 A1 5 *-* b =
>> object1~start("REPEAT",3,"Object 1 running call 2")
>> R1 T1 A1 6 *-* say "a:" a~result
>> R1 T2 A2 V1 >I> Method "REPEAT" with scope
>> "EXAMPLE" in package "G:\oorexx.tmp\concurrencyTrace\example_12_4.rex".
>> R1 T3 A3 V1 >I> Method "REPEAT" with scope
>> "EXAMPLE" in package "G:\oorexx.tmp\concurrencyTrace\example_12_4.rex".
>> R1 T2 A2 V1 1* 12 *-* use arg reps,msg
>> R1 T2 A2 V1 1* 13 *-* do reps
>> R1 T2 A2 V1 1* 14 *-* say msg
>> Object 1 running call 2
>> R1 T2 A2 V1 1* 15 *-* end
>> R1 T2 A2 V1 1* 13 *-* do reps
>> R1 T2 A2 V1 1* 14 *-* say msg
>> Object 1 running call 2
>> R1 T2 A2 V1 1* 15 *-* end
>> R1 T2 A2 V1 1* 13 *-* do reps
>> R1 T2 A2 V1 1* 14 *-* say msg
>> Object 1 running call 2
>> R1 T2 A2 V1 1* 15 *-* end
>> R1 T2 A2 V1 1* 13 *-* do reps
>> R1 T2 A2 V1 1* 16 *-* return "Repeated" msg"," reps
>> "times."
>> R1 T3 A3 V1 1* 12 *-* use arg reps,msg
>> R1 T3 A3 V1 1* 13 *-* do reps
>> R1 T3 A3 V1 1* 14 *-* say msg
>> Object 1 running call 1
>> R1 T3 A3 V1 1* 15 *-* end
>> R1 T3 A3 V1 1* 13 *-* do reps
>> R1 T3 A3 V1 1* 14 *-* say msg
>> Object 1 running call 1
>> R1 T3 A3 V1 1* 15 *-* end
>> R1 T3 A3 V1 1* 13 *-* do reps
>> R1 T3 A3 V1 1* 14 *-* say msg
>> Object 1 running call 1
>> R1 T3 A3 V1 1* 15 *-* end
>> R1 T3 A3 V1 1* 13 *-* do reps
>> R1 T3 A3 V1 1* 16 *-* return "Repeated" msg"," reps
>> "times."
>> a: Repeated Object 1 running call 1, 3 times.
>> R1 T1 A1 7 *-* say "b:" b~result
>> b: Repeated Object 1 running call 2, 3 times.
>> R1 T1 A1 8 *-* say "Main ended." /*
>> concurrently. */
>> Main ended.
>>
>> --------------------------------------- trace example 2 (end)
>> -------------------
>>
>> ---rony
>>
>>
>>
>> On 09.02.2023 13:27, Rick McGuire wrote:
>>> This is one of those features where I think I need to see the complete
>>> documentation written first before any code is checked in. In particular, I
>>> have some reservations on how this explicitly introduces activities and
>>> reservation counts concepts to the language without them ever appearing
>>> elsewhere in the language reference. I'm also not willing to accept the
>>> format with which the additional information is added without some
>>> additional discussion. Also the concept of giving the activities a unique
>>> identifier. Since activities are pooled and reused, it needs to be defined
>>> how that all plays out. This feature, while useful, needs a lot more
>>> discussion before it is put in place.
>>>
>>> Rick
>>>
>>> On Thu, Feb 9, 2023 at 7:21 AM Rony G. Flatscher <rony.flatsc...@wu.ac.at
>>> <mailto:rony.flatsc...@wu.ac.at>> wrote:
>>> Thanks for the feedback. Probably putting M as the trailing letter after
>>> the alphabetic letter as Mike suggests is the best option. Omitting the
>>> trailing M would switch back to the simple form. Would that be acceptable
>>> for everyone?
>>>
>>> ---rony
>>>
>>>
>>>
>>> On 08.02.2023 21:24, Rick McGuire wrote:
>>>> The special symbol characters "." and "_" are also available as
>>>> indicators. I'm a definite -1 to using environment variables and Erich has
>>>> also voiced his displeasure about that.
>>>>
>>>> Another option might be to allow a second keyword following the trace type
>>>> that indicates using the expanded form. It should also allow explicit
>>>> specification of the simple form too.
>>>>
>>>> Rick
>>>>
>>>> On Wed, Feb 8, 2023 at 2:46 PM Mike Cowlishaw <m...@speleotrove.com
>>>> <mailto:m...@speleotrove.com>> wrote:
>>>> I would have put the M after the other letter because it's really a
>>>> subsidiary option. If it's first it rather 'M'asks the main option?
>>>>
>>>> Mike
>>>>
>>>> From: Rony G. Flatscher [mailto:rony.flatsc...@wu.ac.at
>>>> <mailto:rony.flatsc...@wu.ac.at>]
>>>> Sent: 08 February 2023 14:16
>>>> To: oorexx-devel@lists.sourceforge.net
>>>> <mailto:oorexx-devel@lists.sourceforge.net>
>>>> Subject: [Oorexx-devel] Planning to add multithreaded (concurrent) tracing
>>>> (Re: RFC for feature request "794 Concurrency request"
>>>>
>>>> Coming back to this RFE from 17 months ago which I would like to add to
>>>> trunk. Without it one can hardly use TRACE for debugging multithreaded
>>>> programs in a Rexx-like, i.e. easy manner.
>>>>
>>>> Currently having tried to incorporate the feedback about too many
>>>> whitespaces between the new columns (Rexx interpreter instance number,
>>>> Thread number, Activity number, reserved object pool).
>>>>
>>>> There was another idea about making this concurrency/multihreaded trace
>>>> available without a need to define an environment variable
>>>> RXTRACE_CONCURRENCY before starting a Rexx program. This post is about
>>>> ideas of how to activate and deactivate concurrent tracing at runtime
>>>> (either via the TRACE keyword instruction or the TRACE()-BIF) in a manner
>>>> that is intuitive and easy to remember.
>>>>
>>>> One possibility would be to introduce new alphabetic options, this time
>>>> with two letters by prepending the letter 'M' (for multithreaded as the
>>>> letter c is already used for tracing commands and may therefore be
>>>> irritating) to the existing alphabetic characters, hence defining the
>>>> following semantics:
>>>>
>>>>
>>>> Trace
>>>> Option, turn off MT
>>>> Option, turn on MT
>>>> All
>>>> A
>>>> MA
>>>> Command
>>>> C
>>>> MC
>>>> Error
>>>> E
>>>> ME
>>>> Failure
>>>> F
>>>> MF
>>>> Intermediates
>>>> I
>>>> MI
>>>> Labels
>>>> L
>>>> ML
>>>> Normal
>>>> N
>>>> MN
>>>> Off
>>>> O
>>>> -
>>>> Results
>>>> R
>>>> MR
>>>>
>>>>
>>>>
>>>> This would have the benefit that anytime it becomes possible to turn on
>>>> and to turn off multithreaded/concurrent tracing at runtime.
>>>>
>>>> What do you think?
>>>>
>>>> ---rony
>>>>
>>>> P.S.: The "fallback" would be to just add it as is, i.e. using the
>>>> environment variable RXTRACE_CONCURRENCY, making the
>>>> multithreaded/concurrent tracing a global option that needs to be set
>>>> before running a Rexx program.
>>>>
>>>>
>>>>
>>>> On 05.09.2021 14:12, Rony G. Flatscher wrote:
>>>>> Almost a week ago Jean Louis Faucher registered feature request "794
>>>>> Concurrency request", cf.
>>>>> <https://sourceforge.net/p/oorexx/feature-requests/794/>
>>>>> <https://sourceforge.net/p/oorexx/feature-requests/794/> together with a
>>>>> patch that implements the
>>>>> feature request. So far there have been no comments, hence "requesting
>>>>> for comments (RFC)" here as
>>>>> it may be the case that the RFE has been overlooked.
>>>>>
>>>>> ---
>>>>>
>>>>> IMHO this RFE is incredible helpful for debugging multi-threaded Rexx
>>>>> programs and for understanding
>>>>> how ooRexx dispatches multithreaded code.
>>>>>
>>>>> The way Jean Louis devised the implementation has practically no impact
>>>>> on the interpreter (unless
>>>>> one defines an environment variable "RXTRACE_CONCURRENCY=on" modelled
>>>>> after the existing
>>>>> "RXTRACE=ON" environment variable in which case helpful information gets
>>>>> generated for prefixing
>>>>> each trace output statement) makes it easy even for beginners (=
>>>>> students) to get insight and
>>>>> understand how ooRexx executes multithreaded programs. Some problems
>>>>> rooted in multithreaded Rexx
>>>>> code can be quickly located, understood and resolved with this feature.
>>>>>
>>>>> Having tested this concurrency trace feature with the most challenging
>>>>> JavaFX ooRexx programs I have
>>>>> been really impressed with the results. Using the ooRexx program
>>>>> "samples/tracer.rex" (included in
>>>>> the patch) to render the massive concurrency trace output of some JavaFX
>>>>> ooRexx programs to csv and
>>>>> importing the concurrency trace into a spreadsheet (e.g. Excel) makes it
>>>>> possible to analyze such
>>>>> massive concurrency traces in every possible detail using the spreadsheet
>>>>> features (e.g. filtering
>>>>> for a specific ooRexx interpreter instance or specific threads, pivots
>>>>> and the like). Therefore I
>>>>> uploaded one such test to this RFE such that one can directly get at the
>>>>> massive concurrency trace,
>>>>> the csv file created by "tracer.rex" from it and an Excel spreadsheet
>>>>> which was used to import the
>>>>> generated csv file. (I wished this feature had been available when
>>>>> devising some of the BSF4ooRexx
>>>>> JavaFX samples, which would have saved me literally weeks of debugging!)
>>>>>
>>>>> The patch implementing RFE 794 makes it really easy for ooRexx
>>>>> programmers to understand and to
>>>>> debug multithreaded ooRexx programs, saving them a *lot* of time trying
>>>>> to understand what happens,
>>>>> how concurrent statements get executed by the interpreter(s) and locating
>>>>> coding errors!
>>>>>
>>>>> ---rony
>>
>> _______________________________________________
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> <mailto:Oorexx-devel@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>> <https://lists.sourceforge.net/lists/listinfo/oorexx-devel>
>> _______________________________________________
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> <mailto:Oorexx-devel@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
