Re: re-entering threats
Re: re-entering threats
- Subject: Re: re-entering threats
- From: Andy <email@hidden>
- Date: Sun, 18 Aug 2002 19:30:55 -0400
"Gerriet M. Denkmann" wrote:
>
>
2. A function is re-entrant if it:
>
a) does not use global variables
>
b) does not modify its own code (which a normal C programm could
>
not easily do anyway)
>
c) if it handles recursive calls well (is this something I should
>
be concerned of, or is this taken care of by the compiler ?)
>
d) lots of other things (could you elaborate on this?)
How long is a piece of string? I mean, if a class does I/O or interacts
with a database, or changes files, it may not be re-entrant. As you
said above (sorry, I didn't quote it), its usually about whether a
method has any persistant side effects - if the method is effectively
stateless, its will almost always thread safe and re-entrant - with the
possible exception of b) above.
As for "lots of other things" - one thing to consider is subclassing. If
a method alters the state of a class, and it calls other methods, what
happens if a subclass overrides those methods? Might the overridden
method leave things in a bad state? Normally its not your responsibility
what others do with your classes, but if you are writing a library or a
piece of security sensetive code such issues can become important. Java
offers the final keyword to mark a method such that it can't be
overidden. The String class is a classic example - its final and
immutable in order to gaurantee various security properties work. That's
no really about thread safety per se, but I'm trying to discuss what
"the bigger picture" can mean.
>
What confuses me in the documentation is: "All other classes may or
>
may not be re-entrant.", i.e. it talks of classes (not functions) beeing
>
re-entrant or not.
>
I also states explicitly that e.g. NSNotificationCenter is both
>
thread-safe and re-entrant, and that NSNumber is thread-safe, but maybe
>
not re-entrant.
>
Another sentence which I cannot get the meaning of is: "Re-entrancy is
>
only possible where operations "call out" to other operations in the
>
same object or on different objects."
>
Could this really mean that a function (or class?) is only re-entrant if
>
it "calls out" to other operations?
>
Or does it mean: "Non-re-entrancy can only happen where operation "call
>
out"..." ?
>
>
And could you give me an example of such a "calling out" which makes the
>
class re-entrant or not?
I'm not sure I follow these paragraphs either. My personal suspicion is
the key thing they're talking about is recursion. One classic example
might be a write lock. Say a piece of code takes a write lock and enters
a critical section. Within that critical section its necessary for the
code to acquire the same write lock again. Some write lock
implementations recognise the fact the thread in question already has
the write lock, and allow the code to complete. Some are described as
"non-reentrant" and thus don't know the code has a write lock already.
Thus deadlock occurs because the thread waits for the lock - but it will
never get it as it already holds the lock.
That's an example of a thread safe class (the lock is capable of being
used by multiple threads without its state being corrupted) that isn't
re-entrant (if a thread tries to take the same lock twice it deadlocks).
I'm aware the example I've given doesn't really answer your question - I
don't really understand what the documentation is trying to convety
either - but I'm trying to share some of the issues the may be thinking about.
Re-entrancy can also be about recognising something has already entered
a class once, and therefore should be able to re-enter the class with
special priveleges (automatically gets the lock) that other threads
don't have.
--
AndyT (lordpixel - the cat who walks through walls)
A little bigger on the inside
(see you later space cowboy ...)
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.