Home > Archive > Cobol > June 2004 > Reentrancy, Recursion, Threading, etc
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Reentrancy, Recursion, Threading, etc
|
|
| William M. Klein 2004-06-03, 7:00 pm |
| I just wanted to say that "re-entrancy" (sp?) was on the CANDIDATE list for the
2002 Standard at an EARLY stage. During discussion, it was felt (accurately or
not) that the current (2002) and past (all versions) Standards neither "defined"
nor prohibited reentrancy.
So far, nothing that has been stated in C.L.C. makes me think this is wrong.
Certainly the INTENT (and I believe the specifications) of "run-unit" and the
scope of what the Standard sets out to specify simply does NOT address multiple
run units executing simultaneously and how they "share" resources. It *does*
specify what happens to BOTH working-storage and local-storage when multiple
instances of the same program are active within the same run unit. (It also
addresses file section, etc - although that has not come up so far).
As at least one existing implementation supports reentrant code that is invalid
for recursion and recursive code that is not reentrant; it is hard for me
(personally) to see how an "upwardly compatible" Standard specification for
these (that was interactive) could be introduced.
As far as "threading" goes, it is hard for me to imagine the STANDARD specifying
how multiple "thingies" (copies?) of a COBOL program within the same run unit
would work until/unless COBOL defines a way to "activate" multiple threads
within the same run unit. I do KNOW that existing implementations deal with
this - and I think it would be "nice" if a future Standard better
defined/handled this. It is certainly POSSIBLE (but not required) that this
could be addressed when/if "asynchronous" programming was introduced to the
Standard.
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| Robert Wagner 2004-06-06, 3:55 am |
| "William M. Klein" <wmklein@nospam.netcom.com> wrote:
>I just wanted to say that "re-entrancy" (sp?) was on the CANDIDATE list for the
>2002 Standard at an EARLY stage. During discussion, it was felt (accurately or
>not) that the current (2002) and past (all versions) Standards neither
>"defined" nor prohibited reentrancy.
That's true.
>So far, nothing that has been stated in C.L.C. makes me think this is wrong.
>Certainly the INTENT (and I believe the specifications) of "run-unit" and the
>scope of what the Standard sets out to specify simply does NOT address multiple
>run units executing simultaneously and how they "share" resources. It *does*
>specify what happens to BOTH working-storage and local-storage when multiple
>instances of the same program are active within the same run unit. (It also
>addresses file section, etc - although that has not come up so far).
The Standard deals only with recursion, when it says an instance of
Local-Storage will be created upon entry and deleted upon exit. That's fine
because that's all recursive programs need.
That's insufficient for multithreaded programs, which additionally require (at
minumum):
...language to start threads (exit program may be adequate to stop them)
...locks to prevent concurrent writes to shared memory (Working-Storage)
...language to sleep until an event occurs and language to signal an event
>As at least one existing implementation supports reentrant code that is invalid
>for recursion and recursive code that is not reentrant; it is hard for me
>(personally) to see how an "upwardly compatible" Standard specification for
>these (that was interactive) could be introduced.
That's why it should be in the Standard -- because do-it-yourself extensions may
be flawed.
>As far as "threading" goes, it is hard for me to imagine the STANDARD
specifying
>how multiple "thingies" (copies?) of a COBOL program within the same run unit
>would work until/unless COBOL defines a way to "activate" multiple threads
>within the same run unit. I do KNOW that existing implementations deal with
>this - and I think it would be "nice" if a future Standard better
>defined/handled this. It is certainly POSSIBLE (but not required) that this
>could be addressed when/if "asynchronous" programming was introduced to the
>Standard.
"Asynchronous" is appropriate, although multithreading is the more common word.
Multi-tasking was a 'first generation' attempt to do asynchronous computing with
then existing OS facilities. When they were found lacking, multithreading was
invented as a 'second generation' technology to provide better synchronization
services. As some CS type (Michael: are you listening?) will point out, better
mechanisms are already available, and will continue to emerge.
The challenge for a Language such as Cobol is to abstract asynchronicity so it
isn't tied to a particular OS implementation.
| |
| Chuck Stevens 2004-06-07, 3:55 pm |
|
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
news:40c25bda.127204998@news.optonline.net...
> That's insufficient for multithreaded programs, which additionally require
(at
> minumum):
> ..language to start threads (exit program may be adequate to stop them)
PROCESS and CONTINUE in MCP COBOL ('68, '74 and '85), maybe?
> ..locks to prevent concurrent writes to shared memory (Working-Storage)
USAGE LOCK, and the LOCK and UNLOCK statements, perhaps?
> ..language to sleep until an event occurs
USAGE EVENT, WAIT UNTIL event-name, and RESET event-name, maybe?
> and language to signal an event
> CAUSE event-name, maybe?
> That's why it should be in the Standard -- because do-it-yourself
extensions may
> be flawed.
I guess my position is that the *tools to allow* asynchronous processing
should be in the standard. What should not be in the standard are extensive
specifications that limits the functionality for the sole purpose of keeping
the programmer from shooting himself in the foot.
> "Asynchronous" is appropriate, although multithreading is the more common
word.
May be, but the problem is that WG4 has blessed the idea of looking at
"asynchronous processing", but not the idea of "multithreading", and they
don't mean the same thing to all people.
> Multi-tasking was a 'first generation' attempt to do asynchronous
computing with
> then existing OS facilities. When they were found lacking, multithreading
was
> invented as a 'second generation' technology to provide better
synchronization
> services. As some CS type (Michael: are you listening?) will point out,
better
> mechanisms are already available, and will continue to emerge.
We've been doing multi-tasking, multi-threading, multi-programming and
multi-processing using both reentrancy and recursion on Unisys MCP-based
systems with equanimity for around four decades now. Examples of tools that
allow the *user* to do these things already exist.
My opinion is that if the user can declare a "lock item", and the user
transfers control to an asynchronous process that has visibility to that
item, checks that lock and finds it still locked, the bug's in the calling
program for failing to unlock the lock when it was done with the item it
controlled, not with the standard or the compiler. I believe such would
be the case for a number of the rules for asynchronous processing; it is up
to the user to ensure that his data *is* protected; all that is required of
the standard is that it provide standard mechanisms whereby the data *can
be* protected.
The less the standard requires be done "automatically" the better, I
believe.
> The challenge for a Language such as Cobol is to abstract asynchronicity
so it
> isn't tied to a particular OS implementation.
I personally don't think it's that much of an imposition to declare three
new data types as Unisys MCP has them (LOCK, EVENT, TASK) and the syntax to
support access to them as described above. The problem is that some would
regard "already exists in some OS implementation" (in this case, the Unisys
MCP architecture) as sufficient reason to reject the syntax *and* the
functionality on the basis that it is, prima facie, "tied to [that]
particular OS implementation" because the Unisys MCP operating environment
has been providing OS support for LOCKs, EVENTs and TASKs for quite a long
time, and other environments haven't.
-Chuck Stevens
| |
| Warren Simmons 2004-06-07, 8:55 pm |
| Chuck Stevens wrote:
> "Robert Wagner" <robert.deletethis@wagner.net> wrote in message
> news:40c25bda.127204998@news.optonline.net...
>
>
>
> (at
>
>
>
> PROCESS and CONTINUE in MCP COBOL ('68, '74 and '85), maybe?
>
>
>
>
> USAGE LOCK, and the LOCK and UNLOCK statements, perhaps?
>
>
>
>
> USAGE EVENT, WAIT UNTIL event-name, and RESET event-name, maybe?
>
>
>
>
>
>
>
> extensions may
>
>
>
> I guess my position is that the *tools to allow* asynchronous processing
> should be in the standard. What should not be in the standard are extensive
> specifications that limits the functionality for the sole purpose of keeping
> the programmer from shooting himself in the foot.
>
>
>
> word.
>
> May be, but the problem is that WG4 has blessed the idea of looking at
> "asynchronous processing", but not the idea of "multithreading", and they
> don't mean the same thing to all people.
>
>
>
> computing with
>
>
> was
>
>
> synchronization
>
>
> better
>
>
>
> We've been doing multi-tasking, multi-threading, multi-programming and
> multi-processing using both reentrancy and recursion on Unisys MCP-based
> systems with equanimity for around four decades now. Examples of tools that
> allow the *user* to do these things already exist.
>
> My opinion is that if the user can declare a "lock item", and the user
> transfers control to an asynchronous process that has visibility to that
> item, checks that lock and finds it still locked, the bug's in the calling
> program for failing to unlock the lock when it was done with the item it
> controlled, not with the standard or the compiler. I believe such would
> be the case for a number of the rules for asynchronous processing; it is up
> to the user to ensure that his data *is* protected; all that is required of
> the standard is that it provide standard mechanisms whereby the data *can
> be* protected.
>
> The less the standard requires be done "automatically" the better, I
> believe.
>
> so it
>
>
>
> I personally don't think it's that much of an imposition to declare three
> new data types as Unisys MCP has them (LOCK, EVENT, TASK) and the syntax to
> support access to them as described above. The problem is that some would
> regard "already exists in some OS implementation" (in this case, the Unisys
> MCP architecture) as sufficient reason to reject the syntax *and* the
> functionality on the basis that it is, prima facie, "tied to [that]
> particular OS implementation" because the Unisys MCP operating environment
> has been providing OS support for LOCKs, EVENTs and TASKs for quite a long
> time, and other environments haven't.
>
> -Chuck Stevens
>
>
Except, Chuck, when the USER had already extended or created software to
accommodate the problems. I remember our use of IMS, TOTAL, and IDS
before I retired in the mid 80's. Of course we were users of Burroughs,
Univac, RCA, and IBM hardware. If I had a history of Apars or Joint
Extension developments, I feel strongly that your position would be
BACKED UP.
Warren
| |
| Warren Simmons 2004-06-07, 8:55 pm |
| Chuck Stevens wrote:
> "Warren Simmons" <wsimmons5@optonline.net> wrote in message
> news:40C4B8F6.1020100@optonline.net...
>
>
>
>
> If the user has already extended or created software to accommodate the
> problems, I would suggest that the standards folks would be very much
> disinclined to *prevent* such programs from continuing to compile and run.
>
> What I was trying to get at is that if the COBOL standard is to provide
> support for asynchronicity, it seems to me that the basic functionality
> requires user-declarable data items that describe events, locks and tasks,
> and syntactic support for manipulating each. I don't care what the USAGEs
> are called, and I don't care what the statements or extensions are, either.
>
> The Unisys MCP COBOL syntax I've described is independent of any other
> software save the MCP itself, and I think it's a pretty good *functional*
> model for *language syntax* supporting asynchronous processing with a
> minimum of "behind the user's back" stuff. If you wait for an EVENT that
> no program ever CAUSEs, you might wait forever. If you call a program that
> requires that a lock be reset before the program proceed, it's a good idea
> to make sure you reset the lock before you call the program. That sort of
> stuff. I don't care whether the lock is called a LOCK, or whether you CAUSE
> or TRIGGER or PRECIPITATE or ACTIVATE an event, it's the concepts to be
> supported by the syntax that are the concern of the standard.
>
> -Chuck Stevens
>
>
Got it. I was just trying to address that many users had to do things
like this over a long period of time. Some in relationship with Guide,
Share, etc. and some with out any outside help. Something about being
a pioneer makes a lot of this stuff weird to rehash. I forget that
there were other systems besides the big ones. <G>
Warren
| |
| Chuck Stevens 2004-06-07, 8:55 pm |
| And to amplify a little further on what I wrote in ...
> If you wait for an EVENT that
> no program ever CAUSEs, you might wait forever. If you call a program
that
> requires that a lock be reset before the program proceed, it's a good
idea
> to make sure you reset the lock before you call the program. That sort of
> stuff.
If you wait for an "event" that nobody ever "causes", that's a program
error. It's neither the system's job nor the compiler's job to make sure
that the "event" gets "caused", that's your job as application designer.
Likewise, if you call a program that requires a "lock" be "unlocked" before
some resource can be accessed, and the "lock" is still set, that too is a
program error, probably in the program that passes control to the one that's
expecting the available resource.
I grant that such application program errors can be difficult to catch or
even identify, but it's not the language compiler's business to try to catch
or identify them; it's the user's job. It's the user's job to "cause"
events if programs dependent on those events are to wake up, and it's the
user's job to "unlock" resources when other programs cannot continue so long
as the resources are "locked", just as it is the user's job to make sure a
file is open before writing to it.
-Chuck Stevens
| |
| Robert Wagner 2004-06-08, 3:55 am |
| "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
>news:40c25bda.127204998@news.optonline.net...
>
>(at
>
>PROCESS and CONTINUE in MCP COBOL ('68, '74 and '85), maybe?
>
>
>USAGE LOCK, and the LOCK and UNLOCK statements, perhaps?
>
>
>USAGE EVENT, WAIT UNTIL event-name, and RESET event-name, maybe?
>
>
MCP sounds very much like Unix threads, since copied by MS and IBM. As
discussed here, multithreading existed since the late '50s, but wasn't
standardized until the late '80s publication of a Unix library. Sounds like it
may have been inspired by Unisys.The terminology is the same.
[color=darkred]
>I personally don't think it's that much of an imposition to declare three
>new data types as Unisys MCP has them (LOCK, EVENT, TASK) and the syntax to
>support access to them as described above. The problem is that some would
>regard "already exists in some OS implementation" (in this case, the Unisys
>MCP architecture) as sufficient reason to reject the syntax *and* the
>functionality on the basis that it is, prima facie, "tied to [that]
>particular OS implementation" because the Unisys MCP operating environment
>has been providing OS support for LOCKs, EVENTs and TASKs for quite a long
>time, and other environments haven't.
Those objections are unlikely because all major platforms provide very similar
services.
| |
| Chuck Stevens 2004-06-11, 3:55 am |
|
"Warren Simmons" <wsimmons5@optonline.net> wrote in message
news:40C4B8F6.1020100@optonline.net...
> Except, Chuck, when the USER had already extended or created software to
> accommodate the problems. I remember our use of IMS, TOTAL, and IDS
> before I retired in the mid 80's. Of course we were users of Burroughs,
> Univac, RCA, and IBM hardware. If I had a history of Apars or Joint
> Extension developments, I feel strongly that your position would be
> BACKED UP.
If the user has already extended or created software to accommodate the
problems, I would suggest that the standards folks would be very much
disinclined to *prevent* such programs from continuing to compile and run.
What I was trying to get at is that if the COBOL standard is to provide
support for asynchronicity, it seems to me that the basic functionality
requires user-declarable data items that describe events, locks and tasks,
and syntactic support for manipulating each. I don't care what the USAGEs
are called, and I don't care what the statements or extensions are, either.
The Unisys MCP COBOL syntax I've described is independent of any other
software save the MCP itself, and I think it's a pretty good *functional*
model for *language syntax* supporting asynchronous processing with a
minimum of "behind the user's back" stuff. If you wait for an EVENT that
no program ever CAUSEs, you might wait forever. If you call a program that
requires that a lock be reset before the program proceed, it's a good idea
to make sure you reset the lock before you call the program. That sort of
stuff. I don't care whether the lock is called a LOCK, or whether you CAUSE
or TRIGGER or PRECIPITATE or ACTIVATE an event, it's the concepts to be
supported by the syntax that are the concern of the standard.
-Chuck Stevens
|
|
|
|
|