Jump to content
  • Advertisement
Sign in to follow this  

Consumer threads waiting for work.

This topic is 3672 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
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.

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!