I know that c++ doesn't support threads and you need an external library (is that the right buzz word?).
Looked up some but since there are so many I'd thought I'd ask you guys what you like the best and why?
Printable View
I know that c++ doesn't support threads and you need an external library (is that the right buzz word?).
Looked up some but since there are so many I'd thought I'd ask you guys what you like the best and why?
It does, nowadays.Quote:
Originally Posted by JonathanS
std::thread - Cppreference
You can also try Boost's thread for a similar design to standard threads, or Intel's tbb library which is often praised.
Btw, if you are already familiar with gui toolkits like Qt , sfml or anything else, check out their own libraries, which will be easier to learn that foreign designs.
Yes that is a right buzz word.
The only one I've used is pthreads, because everything I do is on linux, and that is the native standard there, among other places. An issue is that threading library must work closely with the OS kernel, so, eg, there is a windows pthreads port, but it is just a wrapper for the native MS thread library. Pthreads I think works natively on OSX, but there is also a seperate Mac threading API, I dunno what the relationship is.
Boost has a thread lib that is probably worth checking out, since it is presumably cross-platform (it will use pthreads where appropriate, the MS lib on windows, etc).
Thread Management - Boost 1.35.0
It looks to me that the means of synchronizing threads is treated separately.
Synchronization - Boost 1.41.0
Which is fine -- while thread safe synchronization is probably pre-requisite to most threaded programming, they don't need to be part of the same API.
WRT the new C++11 std::thread manasij7479 mentions, I guess the parallel means of thread safe synchronization would be:
http://en.cppreference.com/w/cpp/atomic
but again, you could use any thread safe means -- just do not bother trying to make up your own; it is not possible without resorting to processor specific asm calls, I believe.
Oh, maybe I'm wrong, those are older references:Quote:
Originally Posted by MK27
Chapter..28...Thread - Boost 1.49.0
Looks like an umbrella covering threads and mutexes.
If you don't get the distinction between thread management and thread synchronization that is something you should read up on soon.
What is wrong with that ?Quote:
Originally Posted by MK27
A thread safe class might not need to use threads internally.
That's why I said:Quote:
Originally Posted by manasij7479
;)Quote:
Which is fine -- while thread safe synchronization is probably pre-requisite to most threaded programming, they don't need to be part of the same API.
It is, actually. It just isn't pretty, and it's pretty limited and non-efficient.Quote:
Originally Posted by MK27
It essentially required at least n boolean variables where there are n threads. But that's just the bare minimal; any algorithm implementing such primitives is bound to need more.
Anyway, pthreads are for C. Boost and TBB are for C++ and they are pretty good, as I have used them both. TBB is also aimed to be some kind of general parallelization library (that is, you create tasks, and TBB tries to manage the number of threads and the work they do for you), but other than that, they're pretty similar.
Unless the operations on the bools is atomic, I don't see how this is a thread safe design. Even if the bools are each only modified by one thread, they are useless for synchronization if the other threads cannot safely read them (which requires a thread safe, atomic operation).Quote:
Originally Posted by Elysia
I thought it was .. unless you've got a Quantum Computer !Quote:
Originally Posted by MK27
Here is one such algorithm that requires no special instructions: Lamport's bakery algorithm - Wikipedia, the free encyclopedia
It most definitely isn't. Computer architectures aren't exactly simple!Quote:
Originally Posted by manasij7479
To do any kind of synchronization, you need at least a load, a conditional branch, at least one instruction to modify the value you've loaded into a register and finally write back.
But what happens if there's a context switch between the load and the store?
So while it is indeed atomic in the sense that it is only 1 byte (and hence will probably only take one clock to transfer over the bus), it won't necessarily be atomic with regard to the number of instructions.
How 'complex' can a single bit be made ?Quote:
Originally Posted by Elysia
Edit: I see.
First off, a bool isn't a single bit. It's one byte. Today's computer a byte-addressed, not bit addressed.
Secondly, consider what has to happen.
First we load the value. This involves the cpu having to put the address on the bus and somehow signal the memory (this is if we ignore cache). That's one cycle.
Then we have to wait until the memory is ready to transfer the bits to the cpu. This can take many cycles. Count on 10s of cycles.
Then the data has to arrive to the cpu over the bus.
Then we need to execute some conditional branch on the value, which can cause a branch misprediction (and probably will at least once). A branch probably takes one clock cycle, but a branch misprediction is expensive.
Then we need to update the data in the registers to reflect the new state we want to write back. One clock cycle.
Finally, we need to write back. This again implies that we need to wait for the memory to be ready, transfer the bits over the bus and wait for the memory to write the data.
Consider what happens if there is an instruction trying to reference the same position in memory at the same time. This is a very real scenario with multi-core processors.
I wouldn't trust that:Quote:
Originally Posted by Elysia
The "max" call on line 3 involves a non-atomic read thru an array of integer sized variables. If one thread half sets a Number[i] and then another thread calls max() there, the value of Number[i] in the second thread will be set to an UB value. This makes the while condition on line 10 meaningless, since Number could end up filled with completely random junk:Code:1 lock(integer i) {
2 Entering[i] = true;
3 Number[i] = 1 + max(Number[1], ..., Number[NUM_THREADS]);
Code:10 while ((Number[j] != 0) && ((Number[j], j) < (Number[i], i))) {
I cannot vouch for its correctness since I do not fully understand it myself. However, it has been proven correct (though it does require for prerequisites, such as no OOE).
The raw algorithm has been proven correct in an abstract machine that doesn't support concurrency the way it works on most machines in real life and assumes strictly ordered reads and writes.Quote:
Here is one such algorithm that requires no special instructions
Consider a machine with multiple real threads of execution that don't share real (hardware) cache: real thread one may cache the shared "ownership" array and mutates real cache which is distinct from the real cache owned by real thread two. Without memory barriers being thrown across the shared array the logic fails in any number of ways.
In other words, practical implementations in C and C++ for processors with multiple real threads will still need to use primitives that guarantee atomic operations across the real shared array. You can't do that without help from the hardware or operating system.
On the other hard, the raw algorithm works fine for systems with only one single instruction layer and one real thread of execution.
This is true, but in practice the "i" is computed so as to be unique to a given thread.Quote:
If one thread half sets a Number[i] and then another thread calls max() there, the value of Number[i] in the second thread will be set to an UB value.
Soma
Hmmm....Quote:
Originally Posted by Elysia
In that case, why use a read operation at all? Why not just use rand()? If a write operation uses a value derived from a read operation that can be arbitrary, how is it meaningful whether the write operation is then "correct"?Quote:
Originally Posted by http://en.wikipedia.org/wiki/Lamport%27s_Bakery_algorithm#Discussion
I'm not sure what the "Proof" proves either, but if the net result is access to a shared resource whereby a "read operation can return an arbitrary number" then this does not have any practical use value I can think of.
Hey, does tbb have anything over on pthreads? Is it like, better, easier to use, anything like that?
As Elysia points out, pthreads is a C API, if that makes a big difference to you.Quote:
Originally Posted by phylene
TBB looks to me like something built as a higher level API on top of threads, and not a normative threading library, so it depends what you are trying to accomplish. If you want to learn about threading in a traditional sense, I would use something else. But if that doesn't matter and you just want something to provide you with some tools for concurrency, give it a try.
http://en.wikipedia.org/wiki/Intel_T...uilding_Blocks
Of course it is! pthreads is for C, which means it cannot support C++ features.Quote:
Originally Posted by phylene
tbb and boost takes advantage of C++ features to enable flexibility and control, and cleans up properly so you don't create memory leaks.