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 <[email protected]> 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 <[email protected]
> <mailto:[email protected]>> 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 <[email protected]
>> <mailto:[email protected]>> 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 <[email protected]
>>> <mailto:[email protected]>> 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:[email protected]
>>> <mailto:[email protected]>]
>>> Sent: 08 February 2023 14:16
>>> To: [email protected]
>>> <mailto:[email protected]>
>>> 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
> [email protected] <mailto:[email protected]>
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
> <https://lists.sourceforge.net/lists/listinfo/oorexx-devel>
> _______________________________________________
> Oorexx-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
