Jump to content
  • Advertisement
Sign in to follow this  
Cwiddy

Consumer threads waiting for work.

This topic is 3612 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

What is a good method for consumer threads to check for work? Here is the how I am doing it currently: While(true) { If(work to be done){ pop workitem and do it }; Sleep(smallnumber); } Is there a better way rather then having then having the worker threads constantly checking for work. I am working in .Net but I want to know a general solution. I thought about the using the .Net thread pool, but I am not sure if it is what I want due to the restrictions of the library I am working with. It is not thread safe so I need to create an instance per thread (it generates an image but it can take a depending on the data set, it is also closed source so i can't make it thread safe). It also is a slow library to initialize (also initialization is not thread safe) so creating an instance on the fly isn't an option.

Share this post


Link to post
Share on other sites
Advertisement
In pthreads, I'd prefer using locks and condition variables to synchronize access to the shared data, but apparently in .NET this is all bundled together in the Monitor class with lock/SyncLock provided as syntactic sugar in C#/VB.NET respectively. The basic form is something like this:

// acquire the lock.  the object passed to lock() is generally some
// internal *reference* type object. common idiom is to do something like
// private System.Object my_lock = new System.Object();
lock( my_lock )
{
// we have the lock, now we can safely access the shared data. check to
// see if we can do some meaningful work, usually some predicate on the
// shared state. NOTE: always while, never if.
while( ! work_to_do )
{
// we can't do anything now, so we just wait to receive a signal
// from some other thread sharing this resource. this atomically
// releases the lock and puts the thread in a waiting state.
Monitor.Wait( obj );
}

// at this point we have both the lock to the shared state and we've
// satisfied whatever conditions are necessary for meaningful work.
// here you would typically change the state so that it generates
// meaningful work for other threads that might be waiting.
do_work_on_shared_state();

// before we leave the critical section and release the lock, we need
// to signal to other threads that might be waiting that they can try
// to reacquire the lock and check their conditions. NOTE: Pulse()
// will awaken one thread on the waiting queue, whereas PulseAll() will
// awaken all threads on the waiting queue, but regardless only one of
// them will reacquire the lock.
Monitor.Pulse( obj );
}
// lock is released.

That basic layout can be used for producer/consumer types of thread sychronization and can be modified to do more sophisticated patterns like reader/writer. It's also more likely to ensure you're threading logic is correct and help prevent from certain types of threading problems. This pdf has some more information on using monitors/locks/condition variables for doing synchronization between threads.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!