NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/programm/3320

Text File | 1992-12-14 | 3.6 KB | 73 lines

Newsgroups: comp.programming
Path: sparky!uunet!haven.umd.edu!ames!agate!linus!linus.mitre.org!crawford
From: [e-mail] (Randy Crawford)
Subject: Re: reentrant code
Message-ID: <[e-mail]>
Originator: [e-mail]
Sender: crawford@boole (Randy Crawford)
Nntp-Posting-Host: boole.mitre.org
Organization: The MITRE Corporation, McLean, VA
References: <[e-mail]3> <[e-mail]> <dak.724201089@messua> <[e-mail]> <[e-mail]>
Date: Mon, 14 Dec 1992 16:01:10 GMT
Lines: 59


In article <[e-mail]>, [e-mail] (Michael J. Grier) writes:
>
> In article <[e-mail]>, [e-mail] (Randy Crawford) writes:
> |>
> |>>The problems of reentrancy are a bit different from concurrency.
> |>
> |>True, but reentrancy is irrelevant unless concurrency in some form (like
> |>context switching) is involved.
> |>
>
>    Untrue.  Consider a module which implements an abstraction of a queue
> or other searching structure, which provides a service for iteration on the
> data structure.  If you specify the service such that the caller provides
> a function to execute for each element in the structure, there is again
> a need for reentrancy controls of some fashion.

Only if one part of the search cannot continue to completion before another
part begins (or resumes).  This is still concurrency (or concurrent sub-
tasks) no matter how you look at it.  When you have communicating concurrent
threads/processes/tasks/contexts/callbacks, you have concurrency.

>
>    The reentrancy controls may be as simple as documenting, "Do not attempt
> to modify the data structure from the callback function.  If you do, the
> world may come crashing down about your ears."
>
>    On the other hand, you might try to do something more intelligent and/or
> pro-active in the area, either setting a "busy" flag for the data structure,
> and/or making a copy of the data before beginning the iteration process.
> This takes time and memory.  [I prefer to provide both sorts of interfaces -
> ones which are faster but have more operational constraints, and safer ones
> which cost more.]

Busy flags are unnecessary unless you have multiple concurrent (sub)tasks.
Why have a busy flag unless at least two entities need to know whether a
common resource is available?  This necessarily implies some form of resource
sharing and therefore, concurrency.  Resource sharing isn't a problem if only
one agent at a time requests them.

When you reduce the dining philosopher problem to one live philosopher and
two dead ones, you no longer have any problem sharing resources -- and no
more concurrency.

>
>    My point is that reentrancy isn't a Boolean valued quality of a particular
> service/procedure/function.  You may be reentrant from a signal point of
> view, but not from a multi-threaded point of view.  My first example does not
> use concurrency according to any definition with which I am familliar.

A `signal-reentrant' point of view is no different from a `multi-threaded' point
of view in terms of resource use -- both are composed of multiple executing
contexts which must share common resources, possibly at the same time.  In those
terms, both are undoubtedly forms of concurrency.
--

| Randy Crawford        [e-mail]        The MITRE Corporation
|                                                 7525 Colshire Dr., MS Z421
| N=1 -> P=NP           703 883-7940              McLean, VA  22102