Re: [clisp-list] state of MP (threads)

[Kaz K. <kky...@gm...>]

On Mon, Jan 26, 2009 at 3:33 PM, Sam Steingold <sd...@gn...> wrote:
> Hi,
>
> Vladimir Tzankov wrote:
>>
>> With POSIX-THREADS all exported thread functions are implemented with
>> exception of: THREAD-WAIT and THREAD-STATE. The first should do some
>> polling when the predicate is not a lock. For the latter - I am not
>> sure that it is needed at all.
>
> I think it is useful to be able to find out whether a thread is sleeping or
> running.

I do not agree.

This kind of operation, though seemingly useful on the surface, is not
useful in robust multithreaded programming.

Why it seems useful is obvious. A thread is an object, right? And it
has states like running and sleeping. So why not have accessors for
the state?

The question is, what are you going to do with them. Their use is
fraught with race conditions. By the time you make any decision  based
on whether a thread is sleeping or not, that state could have changed.

Suppose that a thread is one instruction away from making a blocking
system trap into the kernel. Do you regard that thread as sleeping?
Why or why not?

Do you try to use the information to try to manage the thread? E.g.
``if thread is not sleeping, put it to sleep?''  Isn't that trying to
do the scheduler's job, only without having access to the kernel data
structures to do it properly?

You can use threads to write active objects (i.e. higher level
abstractions over threads) which exhibit such states, and do exactly
what you want according to some sane concurrency rules. I.e. some
multithreaded object can have an "active" and "inactive" state, along
with thread-safe mechanisms to request a transition from one to the
other, and be notified of its completion. To implement things like
that, you don't need to peek at low level thread states.