What does mean to join threads or share their ownership?
What does mean to join threads or share their ownership?
The term join may not be what you think. It means to join a new thread to the current process. One process can have many threads. It always has one. And you can simulate multi-tasking by creating a new thread and joining it to the current process.
Shared ownership (in the context of threads. The term also coins a smart pointer technique) goes hand-in-hand with another concept. That of locks. A thread may request two type of locks on a resource (usually an object); shared or exclusive. By far the most usual type is exclusive. In this case any other thread wanting to access that resource will have to wait for the former one to release the lock.
With shared ownership (very dangerous if one doesn't know what they are doing), a thread that tries to access the shared resource will be granted said access as long as the object doesn't have already an exlusive lock on it. This means more than one thread can access the resource at the same time.
If any of those threads change the resource state, you will have a very hard bug to deal with. If both threads don't change the resource (they don't for instance alter the state of an object), then it's pretty safe to use.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Join, as Boost.Threads uses it, means to wait for a thread to finish.Originally Posted by Mario F.
What's the difference between that and not having any synchronization at all?With shared ownership (very dangerous if one doesn't know what they are doing), a thread that tries to access the shared resource will be granted said access as long as the object doesn't have already an exlusive lock on it. This means more than one thread can access the resource at the same time.
But again, that's not what the Boost.Thread docs mean by shared ownership. They only place they contain this term is in the rationale of making the thread class non-copyable, saying that if several [i]objects[/b] wish to share ownership of a thread (as in, the last of the objects to be destructed will destruct the thread object) they should just use a shared_ptr.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
> What's the difference between that and not having any synchronization at all?
Well, for threads implementations that allow this, it means you are granted access if you request a shared lock on resource that already has a shared lock or no lock at all.
> But again, that's not what the Boost.Thread docs mean by shared ownership. They only place they contain this term is in the rationale of making the thread class non-copyable
I didn't use boost::threads to answer that because the term shared ownership is not know in that implementation. So I just recalled what I have read before about threading implementations.... particularly this document on the open standards website:
http://www.open-std.org/jtc1/sc22/wg...006/n2139.html
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Hmm ... would that be like a single-writer-multiple-reader lock?
All the buzzt!
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
If I get it right, it can be implemented if your first obtain a exclusive lock for the writing. All shared locks will then gain wait state.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
