Re: Context switching woes

[Erik <br0ke@math.smsu.edu>]

> 
> Mark Collins wrote:
> > 
> > I'm plan on having a thread management thread (which won't ever be locked)
> > to wake up threads...
> > 
> > Something like this... (pseudocode)
> > 
> > for each lockable resource
> >     if not locked
> >         if thread waiting
>           ^^^^^^^^^^^^^^^^^
> But that's just the heart of my question :( How to test if given thread
> is waiting on mutex? Or, vice versa, since each process will have it's
> own mutex, how to test that there's a thread waiting for given mutex?
> 

global variables are shared across thread instances, threads do NOT have
their own mutex structures, they're global (same with semaphores)

> > sleep for a short time
> 
> But this will increase either load or latency or both :(. I would prefer
> the scheduling thread be woken up by releasing it's mutex by the thread
> just going to sleep. I need cooperative context multitasking. If you
> need, I can elaborate more

sleeping a short time might be sleep(0) to force the thread to give up its
place in the process scheduler queue, the only load and latency increase
should be from context switches, which should be very small as usually
only a couple processes are queued up as 'ready' and someone stated

cooperative multitasking is fairly easy to fake in a preemtive system with
the use of mutexes and dummy system calls. Please read some
documentation on how to do multithreaded programming, particularly
the stuff on mutex handling :)

> 
> 					Jarda Benkovsky
        -Erik <erik@smluc.org> [http://math.smsu.edu/~br0ke]

The opinions expressed by me are not necessarily opinions. In all
probability, they are random rambling, and to be ignored. Failure to ignore
may result in severe boredom or confusion. Shake well before opening. Keep
Refrigerated.

---------------------------------------------------------------------
To unsubscribe, e-mail: linuxgames-unsubscribe@sunsite.dk
For additional commands, e-mail: linuxgames-help@sunsite.dk