🚀 go-pugleaf

In article <32054@ucbvax.BERKELEY.EDU> jamin@cogsci.berkeley.edu.UUCP (Sugih Jamin) writes:
>I am having problem dynamically creating and killing threads.  Suppose I am a 
>function that gets called everytime a thread is to be spawned.  If I allocate
>a stack for the thread in my own stack, then that stack is going to get
>de-allocated everytime I exit.  If I using the heap space for the thread
>stack, who will be freeing it?  Definitely not the thread itself?
>Am I suppose to manage all those stacks also?  Such is not the case in Mach,
>I think.

You need to manage your own stacks.  There are a couple of ways I can
think of to free a stack correctly, I'm sure there are more:

	Thread A	Thread B
			Take Sem
	Wait on Sem	
			DosEnterCritSet (turns off thread switching for
					the process)
			Release Sem
			DosExit
	Free B's stack

The key point to remember is that DosExit clears an existing critical
section.

If you don't want to do the EnterCritSec (which is a bit rude since
it pretty much shuts down your application) you can have A and B wait
on a system semaphore and have A wake up with ERROR_SEM_OWNER_DIED.

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

This does not currently exist, but may in the future.  Right now you
have to have to keep track of who you've spun off.  Most apps I've
written somewhere have a bit array corresponding to thread id's, so
I can scan it to see who's alive.

>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.  

I'm sure it's possible to do what you're trying to do, but I haven't
done it yet and don't have the time at the moment.  As far as FIFO
goes, the scheduler is priority based, meaning that the highest priority
thread waiting on a resource will be the first one scheduled, regardless
of when he did the wait.  This prevents low priority threads from holding
resources needed by high priority guys and gumming up the works.  As
far as threads with equal priority goes, you will probably see FIFO
response within a given priority group, but it isn't guaranteed.


Disclaimer: My opinions are my own, and do not reflect the opinions
or policies of Microsoft.  I also reserve the right to be wrong.
-- 
Robert Reichel
robertre%microsof@beaver.washington.edu or 
{decvax,uunet,uw-beaver}!microsoft!robertre