🚀 go-pugleaf

In article <32054@ucbvax.BERKELEY.EDU> jamin@cogsci.berkeley.edu.UUCP (Sugih Jamin) writes:
>Am I suppose to manage all those stacks also?

I'm afraid so.

>Another question relating to threads, do you know how to tell if you have 
>any thread running?  Some API calls that serve an analogous purpose to
>DosCWait(), but for threads will be nice.

You can roll your own DosTWait() (wait for thread) fairly reliably.
You just code a sleep loop which does something harmless to the thread
like, say, attempting to get its priority.  When you gets the No Such
Thread error (sorry, no manual handy), the thread has finished.

This is useful in waiting for the thread to finish so you can dispose
of its stack.

The only problem is that the threadid might be quickly re-used between
the old thread terminating and a new one starting; this problem can be
gated away.

They really should have put in a DosTWait() and automatic stack
allocation, though.

>According to all I have read on OS/2 semaphores, it seems like not only don't
>they support counting semaphores, they don't even eliminate the problem of
>race condition because any thread could be scheduled next.  OS/2 has three
>different kinds of semaphores with ten(?) semaphore functions, yet none of
>them are as powerful as the one defined by Dijkstra?  What I want is a counting
>semaphores with a FIFO queue. Sometime ago somebody wrote an article in the
>Microsoft Systems Journal showing how one could "easily" implement a counting
>semaphore using the available APIs.  But the counting semaphore he showed
>did not have a FIFO queue associated with it, so one still has the race
>condition.  Please correct me if I am wrong.  

Yes, sorry, they should have got that right too.


-- 
Esmond Pitt, Computer Power Group
ejp@bohra.cpg.oz