Jump to content
  • Advertisement
Sign in to follow this  
Mr_Fox

Suggestion wanted for building bricks of threadpool on Windows

This topic is 558 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

Hey Guys,

 

Recently, I am looking for an efficient and lightweight threadpool library to learn and play with. I haven't implemented one myself yet, but I guess the critical part is kinda of concurrent job queue (right?). And since I have a little experience with concurrent data structure I only prefer lockless ones with atomic with memory barrier, so I was expecting to find some threadpool implementations which are not using heavy lock (like mutex)....  However, after a while I found almost all light-weight threadpool are using std::condition_variable which need mutex.... 

 

So I wish to know whether you guys know some efficient lightweight threadpool implementation. 

 

Also it will be great if someone could talk about the tricky part of implementing threadpool without using heavy lock.

 

Thanks

 

 

P.S. I remember there was a famous talk about 'fiber' which is a totally different small thread library get used in one game engine. Anyone know any good resource about it?

Share this post


Link to post
Share on other sites
Advertisement

So, what are you going to do with a thread that has no work, or with a thread that needs access to data but it is being modified by someone else, so it has to wait?

 

Condition variables are the primary means to block, waiting for new work. Mutexes are the primary means to protect data from being modified while you make a copy.

 

 

 

Edit: The normal procedure is that you use mutexes etc for protecting shared data, and condition variables for waiting for your turn.

Inside a protected area you typically make sure the data you will work on is not shared anymore, so you can just work with it without locking things.

Once done, you claim the area to dump the result, and make the result available for others.

 

The idea is that you spend very little time in protected areas, so they don't become the bottleneck in the system.

 

 

While I think mutexes and condition variables aren't exactly heavy weight, even if they are, it doesn't matter, as a thread mostly runs outside shared data, and doesn't need locks etc.

Edited by Alberth

Share this post


Link to post
Share on other sites

Look at JobSwarm on John Ratcliff's blog. I've never used it, but it sounds like what you're looking for.

Thanks, that looks great. But the latest version is 2009 though, I also wish to learn something utilize latest c++ thread primitives, I know the underhood idea is most important, but I also wish to see how new c++ thread primitives effectively take action in such lock-free library :)

Share this post


Link to post
Share on other sites

So, what are you going to do with a thread that has no work, or with a thread that needs access to data but it is being modified by someone else, so it has to wait?

Yes, that was my main concern too,  I've heard that condition_variable is very handy and effective for dealing idle thread (where spinlock-flag check will saturate CPU in such case...) So I do check how condition_variable notification works, and only be able to trace down such API call in xthreads.h

 
_CRTIMP2_PURE int __cdecl _Cnd_wait(_Cnd_t, _Mtx_t);
 
and I can't find anything useful about that on internet anymore....  and that line seems also indicate the fundamental notification mechanism need a mutex.....
 
So I really wish to find something like std::condition_variable but not use mutex
Thanks

Share this post


Link to post
Share on other sites

pthread implementations should have all the details, I'd be surprised if you couldn't find source of it.

My guess is that it's running on top of a thread API of the OS.

 

I would say the core primitive is the mutex, You can use that as a queue too, which was the way to block threads before we had pthreads. (Ie, all threads try to claim a mutex. Only one succeeds, all others are blocked until the thread owning the mutex releases it.)

 

From the implementation recommendations on using condition variables, it seems to me that a condition variable is some sort of queue, probably backed up by a few OS primitives. Having it basically detaches queue management from the semaphore handling, which may be a good idea. Perhaps reading about the design origins of pthreads explains how they reached the current division of labor.

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!