TinyThread++

[asanjuan]

Hi all.

I'm in the process of implementing a basic parallel search, and I want it to be portable.
I found this library searching on internet:
http://tinythreadpp.bitsnbites.eu/

It is basically a set of wrapper classes that uses the POSIX threads, or the Windows API depending on the platform.

It also has mutex, fast mutex (asm) and condition mutex.

Has anyone used it inside a chess engine?

[mar]

Hi,
no I haven't, I wrote my own wrappers.
From a quick look, condition_variable is equivalent to event on windows, fast mutex is actually spin lock. xchg on x86/x64 implies lock so it should work.
Howevever you should avoid using spin locks on 1 core machines.
Other than that, it looks fine.
Sleep on unix systems is somewhat tricky because it can be usually woken up by receiving SIGALRM,
so in my recent project I combined usleep with a loop where I measure actual elapsed time,
but this is probably useless if you sleep for tiny amounts of time and don't do anything special.

[Rein Halbersma]

The TinyThread++ site asks two questions: don't you have C++11 and can't you use Boost? If you can have either of those two, I would definitely use them because there is a lot more documentation available for std::thread and boost::thread.

[asanjuan]

The TinyThread++ site asks two questions: don't you have C++11 and can't you use Boost? If you can have either of those two, I would definitely use them because there is a lot more documentation available for std::thread and boost::thread.

Since I'm using an old version of VS2005, my compiler doesn't support C++11... So I started to look for something portable and simple.

But ok, I'll try to setup an environment to test the c++11 threads. It's a pity, I really like VS.

[mar]

Since I'm using an old version of VS2005, my compiler doesn't support C++11... So I started to look for something portable and simple.

But ok, I'll try to setup an environment to test the c++11 threads. It's a pity, I really like VS.

Well I'll give you a simple question, do you prefer to depend on 16kb or 90mb of third-party code? I would personally choose neither and would write my own of course.
Problem with C++11 libraries is that there are still some bugs, especially regarding concurrency, but of course that depends on platform.
If you want full control over what's happening, do it yourself (=wrap OS functionality, that's what C++11 libs/boost do anyway, except maybe for some clever hacks).
Also I don't like the fact that std::thread creates the thread in constructor, this is bad design choice, if you subclass std::thread it's game over (even though it's not the intended use case).
Having a custom wrapper has one important benefit - it doesn't matter whether you internally use the OS directly or use C++11 if available,
you are completely shielded from the underlying implementation!

[asanjuan]

Then, it looks like the smart solution is to learn from the TinyThread++ code and implement an easy Thread Pool class, that is what I really need, with some thread status (sleep, waiting... etc.)

If I find time to implement it, i will share it.

next step would be to implement my own parallel perft and learn from the experience...

This is a lot of job to be done.

Thanks Martin.

[Rein Halbersma]

Well I'll give you a simple question, do you prefer to depend on 16kb or 90mb of third-party code? I would personally choose neither and would write my own of course.
Problem with C++11 libraries is that there are still some bugs, especially regarding concurrency, but of course that depends on platform.
If you want full control over what's happening, do it yourself (=wrap OS functionality, that's what C++11 libs/boost do anyway, except maybe for some clever hacks).

Full control is an illusion at worst, and a very expensive dream at best. You might as well grow your own vegetables, knit your own clothes and build your own house to rule out any chance of insecticides, child labor and asbestos roofs etc

Or you might trust that there is something as specialization and profit from economies of scale, and that large food/clothing/manufacturing and software organizations are actually expert-level and that they make stuff not nearly as buggy as what you could produce on your own. NOTE: I'm not saying use whatever library there is without thinking. By all means, shop around and pick what is best for your circumstances. But the Do It Yourself attitude will lose in the long run.

[mar]

Full control is an illusion at worst, and a very expensive dream at best.

It's reality and works very well for me My code does exactly what I want and exactly the way I want it to (read it does nothing unexpected behind the curtains).

Or you might trust that there is something as specialization and profit from economies of scale, and that large food/clothing/manufacturing and software organizations are actually expert-level and that they make stuff not nearly as buggy as what you could produce on your own.

Actually that is an illusion (not to mention quality, if you believe big companies produce hq software, I'm not the crazy one here).
Respect is nice, more than that could be dangerous.
As for my code: it's stable at the moment, runs across several platforms and depends on exactly zero third party libraries
(this is my new philosophy, maybe I just went totally crazy
Another thing is it does nothing special right now, but I'm in the "laying ground" phase.
I trust myself and prefer to fix with my own bugs because I know my code very well.

But the Do It Yourself attitude will lose in the long run.

But quite the contrary! It's actually a HUGE win.
Those libraries you talk about were written by someone and that someone did it himself (themselves).
How many times did you get a buggy new library version here and there (being afraid and reverting to old version), tons of warnings, how long did it take you to seamlessly integrate some third-party library?
Wait it won't compile on that platform, I have to wait for a new version...
Or they just completely revamped the whole interface, nice
So in the end you spend more time twiddling with third party code than writing your own.

If you ever ran into problems with third-party libraries (like zlib reading uninitialized memory etc. - but hey it's ok, they say, it's for performance reasons , you know what I'm talking about.

I'm not talking about writing your own operating system or compiler (I'm not that crazy - but there are people out there who could do that).
I'm talking about thinking carefully about how much dependencies you drag into your (very small if it's a chess engine) project.
Last thing, what do you enjoy more? Programming or gluing third-party/middleware stuff together? I prefer the former.

[michiguel]

Full control is an illusion at worst, and a very expensive dream at best.

It's reality and works very well for me My code does exactly what I want and exactly the way I want it to (read it does nothing unexpected behind the curtains).

Or you might trust that there is something as specialization and profit from economies of scale, and that large food/clothing/manufacturing and software organizations are actually expert-level and that they make stuff not nearly as buggy as what you could produce on your own.

Actually that is an illusion (not to mention quality, if you believe big companies produce hq software, I'm not the crazy one here).
Respect is nice, more than that could be dangerous.
As for my code: it's stable at the moment, runs across several platforms and depends on exactly zero third party libraries
(this is my new philosophy, maybe I just went totally crazy
Another thing is it does nothing special right now, but I'm in the "laying ground" phase.
I trust myself and prefer to fix with my own bugs because I know my code very well.

But the Do It Yourself attitude will lose in the long run.

But quite the contrary! It's actually a HUGE win.
Those libraries you talk about were written by someone and that someone did it himself (themselves).
How many times did you get a buggy new library version here and there (being afraid and reverting to old version), tons of warnings, how long did it take you to seamlessly integrate some third-party library?
Wait it won't compile on that platform, I have to wait for a new version...
Or they just completely revamped the whole interface, nice
So in the end you spend more time twiddling with third party code than writing your own.

If you ever ran into problems with third-party libraries (like zlib reading uninitialized memory etc. - but hey it's ok, they say, it's for performance reasons , you know what I'm talking about.

I'm not talking about writing your own operating system or compiler (I'm not that crazy - but there are people out there who could do that).
I'm talking about thinking carefully about how much dependencies you drag into your (very small if it's a chess engine) project.
Last thing, what do you enjoy more? Programming or gluing third-party/middleware stuff together? I prefer the former.

I have my own wrappers. It is really no big deal. They all mimic the pthread libraries (the name is mythread_etc), so the wrappers for pthreads are a no brainer, and I just need to make an equivalent using the functions provided by windows. I do not need to make wrappers for everything, just for what I use which is a small fraction of the libraries.

Since OS X does not support certain things (they have a phony pthread support) I needed to implement semaphores myself. I googled how to do it and it was not so terrible. Even if a system tells you it supports a particular library, they may come with exceptions too...

Miguel

[mar]

I have my own wrappers. It is really no big deal. They all mimic the pthread libraries (the name is mythread_etc), so the wrappers for pthreads are a no brainer, and I just need to make an equivalent using the functions provided by windows. I do not need to make wrappers for everything, just for what I use which is a small fraction of the libraries.

Since OS X does not support certain things (they have a phony pthread support) I needed to implement semaphores myself. I googled how to do it and it was not so terrible. Even if a system tells you it supports a particular library, they may come with exceptions too...

Miguel

Yes it's not a big deal plus you can always change the underlying implementation as necessary without having to mess with the rest of the code.
Usually multi-platform development in my case boils down to

Code: Select all

#if WINDOWS
    ... do it the non-standard way using WinAPI ...
#else
    ... do it standard way ...
#endif

I ran into a problem recently, OSX (and bsd-based systems) don't support open64, lseek64 (which is available in Linux).
So I'm stuck with up to 4GB files on such systems.
This is a bit off topic but should someone know a low-level solution for handling >4G files on bsd-family systems, it would be more than welcome
EDIT: ok it's not a problem because off_t is 64-bit on such platforms so I actually can seek >4G files simply using lseek