Re: Reentrancy, Recursion, Threading, etc

From: Chuck Stevens (charles.stevens_at_unisys.com)
Date: 06/07/04 

Date: Mon, 7 Jun 2004 11:06:22 -0700

"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

Relevant Pages

  • Re: Reentrancy, Recursion, Threading, etc
    ... Chuck Stevens wrote: ... >>That's insufficient for multithreaded programs, ... > USAGE LOCK, and the LOCK and UNLOCK statements, perhaps? ... What should not be in the standard are extensive ...
    (comp.lang.cobol)
  • Novell VPN 3.8 Client and XP security privledges
    ... My company uses Novell VPN 3.8 Client for remote users. ... huge spyware problem so I have created a standard to lock down machines. ...
    (microsoft.public.security)
  • Re: Reference for proper handling of PID file
    ... There is no general standard for PID files. ... knowing how best to check the lock. ... be stale. ...
    (comp.unix.questions)
  • Re: [patch] spinlocks: remove volatile
    ... not follow the C standard on modern hardware. ... But gcc would follow the standard if it emitted a 'lock' ... standard is that the compiler does not optimize and cache seemingly ... the 'lock' mechanisms should be used in complex situations. ...
    (Linux-Kernel)
  • Re: Reentrancy, Recursion, Threading, etc
    ... >> That's insufficient for multithreaded programs, ... >USAGE LOCK, and the LOCK and UNLOCK statements, perhaps? ... >> ..language to sleep until an event occurs ... >new data types as Unisys MCP has them and the syntax to ...
    (comp.lang.cobol)
Loading