John Max Skaller wrote:
>
> Perhaps I didn't explain myself well. I understand there
> is a problem with in_channel and out_channel. This same problem
> can arise with Unix.descr files (although there is a rich enough
> facility
> to avoid this problem by always doing non-blocking operations?)
>
It is not really a "problem". It is just that they can help a GC
collects blocked thread (see below).
> I guess the same happens with Event.channels?
>
All what I said is only for Event.channels and no other types of
channels.
Perhaps I didn't explain myself well too !
> My question is really: isn't the scenario you describe
> more general? Is there some way that your solution can be applied
> to a wider class of resources than in/out channels?
The point is to try to make the GC collect blocked threads. And the
algorithm I described is needed and you do not need really more (or more
exactly you can not hope for more because a GC can not be perfect)
Let us examine how a thread can be blocked forever:
- blocked on a channel (in/out or both): this can be solved by the
extended GC.
- blocked on a file: you can do nothing: the GC can not scan the outside
world!
- blocked on a mutex: If the thread never wakeup it means that someone
forgotten to release a ressource. This is probably a bug of the program,
it is not really necessary for the GC to care.
- blocked on a condition: Same reasonning than for mutex.
- blocked waiting for another thread: this is also probably a bug.
but in this case it is probably OK for the GC to collect all thread
waiting for a thread which can be itself collected.
To extend the GC with the three last cases you can see that they are
easely codable using in/out channels and get the proper behavior. Notice
that coding with general channel (not in/out) would not lead to the
proper behavior of the GC !
Let us do it for the join operation (waiting for another thread):
You use an out channel for each thread where you send (broadcast)
something as soon as you terminate.
You use the in part of the out channel of a thread to wait for it.
If a thread A is blocked waiting on another thread B which is "dead" for
the GC. Then the GC will not scan the out channel and will detect that
the first thread is dead two (no accessible pointer on the out channel).
If another thread has a pointer on the in part of the out channel there
is no problem. But if we did not make the in/out distinction, then the
GC could not collect anymore the blocked threadv A.
Conclusion: every thread should be considered by the GC as an out
channel which is visible by the GC if the thread is alive. Waiting for a
thread is considered as waiting on the in part of the channel.
I think the mecanism I described is standard in language like pict,
isn't it ? And it shoud (must) be in any language with threads and GC.
-- Christophe Raffalli Université de Savoie Batiment Le Chablais, bureau 21 73376 Le Bourget-du-Lac Cedextél: (33) 4 79 75 81 03 fax: (33) 4 79 75 87 42 mail: Christophe.Raffalli@univ-savoie.fr www: http://www.lama.univ-savoie.fr/~RAFFALLI
This archive was generated by hypermail 2b29 : Mon Mar 06 2000 - 14:14:55 MET