Re: Reentrancy, Recursion, Threading, etc

From: Warren Simmons (wsimmons5_at_optonline.net)
Date: 06/07/04

  • Next message: Chuck Stevens: "Re: Reentrancy, Recursion, Threading, etc" 
    Date: Mon, 07 Jun 2004 18:50:20 GMT

    Chuck Stevens wrote:
    > "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
    >
    >
    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

  • Next message: Chuck Stevens: "Re: Reentrancy, Recursion, Threading, etc"

    Relevant Pages

    • Re: Reentrancy, Recursion, Threading, etc
      ... USAGE LOCK, and the LOCK and UNLOCK statements, perhaps? ... What should not be in the standard are extensive ... We've been doing multi-tasking, multi-threading, multi-programming and ... new data types as Unisys MCP has them and the syntax to ...
      (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
      ... Chuck Stevens wrote: ... > If the user has already extended or created software to accommodate the ... I don't care what the USAGEs ... > to make sure you reset the lock before you call the program. ...
      (comp.lang.cobol)
    Loading