Re: Generational GC in multithreading

[Sam S. <sd...@gn...>]

Hi,

Vladimir Tzankov wrote:
> On Aug 18, 2008, at 6:23 AM, Sam Steingold wrote:
>> I think it's good to be able to figure out the state of a thread.
> 
> Generally (and philosophically) I think there are just 2 thread  
> states - running and finished.

I think that a thread which called yield or sleep should be in a distinct state.

> According to me we should not provide mechanism thread to control the  
> execution of another thread (I mean calls like suspend/resume/kill).  
> All scenarios that require thread cooperation should be implement via  
> the synchronization primitives - mutexes, conditions, semaphores, etc.

that is the best, of course, but sometimes a non-cooperative interaction is 
necessary, e.g., when a thread runs amok it should not be necessary to kill the 
whole process to regain control over the computer, we should be able to kill 
the bad thread from another one.

> When a thread is suspended/killed without it's cooperation - it may  
> happen that it holds some locks (even system ones) that may cause  
> deadlocks in other threads.
> (of course we may define safe for suspend points - which generally  
> are different than safe for gc because of the locks - but this will  
> just add complexity)

yes, this is not going to be easy :-(

> Even if this was not the case - it is not good idea to use suspend/ 
> resume for synchronization purposes.

indeed.

> The only situations where suspend/resume is important - is during GC  
> and debugging - the debugger should be able to suspend all threads  
> (without the itself).

I think the debugger is not the only place when you want to be able to control 
other threads.
even though with-timeout is now implemented without lisp (and thus does not 
need kill/suspend/resume &c), others might want to implement something similar 
with a different feature sent, requiring kill/suspend/resume.

we can also take a look at other MT systems: do they normally offer 
kill/suspend/resume?