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> 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 > 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