Ward William E PHDN wrote:
> Reentrant is more than just that. It also means that if a thread is
> killed, at any point short of completion of the thread, I can restart
> the thread from the original starting parameters and it will perform
> properly.
Actually, not really. Someone else gave an expanded explanation, with
examples, so I'll just give a CS-jargon laden one (since I'm at work and,
ostensibly, the client is paying for this time...)
Reentrancy simply addresses the question of consistent deterministic
behavior for multiple sequential or concurrent instantiations of a
given reentrant object. You're talking about persistent intermediate
state preservation, which, strictly speaking, is NOT defined as part of
reentrancy, but rather the definition of which is a characteristic of
meeting the requirement for determinancy. (*whew*! Say THAT 5 times.)
That is, whether or not data objects being operated upon by a reentrant
process, thread, or function (reentrant object) that is abnormally or
prematurely terminated (a) revert to the state in effect at the
beginning of that thread of execution, or (b) checkpoint to retain any
partial processing done before the termination is irrelevant--it's up
to the developer and his/her application requirements.
What is relevant is that no unexpected interoperation occurs between
reentrant objects (e.g., two instantiations of a given object try to
carry out the same operation on the same objects without coordination)
and that no reentrant object ever relinquishes control without leaving
persistent data objects in a consistent state.
Cheers,
--
Dave Ihnat
[EMAIL PROTECTED]
--
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.
