What's the purpose of joining threads?

Question

1.00/5 (1 vote)

See more:

Is it necessary? What's the purpose? am asking, because I have noticed that it mess up my synchronization. I have one thread called Sheep and Wolf and Sheep manipulates a global variable and when I join them, it messes up the synchronization between the Sheep thread. The sheep threads uses a class lock.

Posted 18-Oct-13 14:28pm

Member 10338805

Add a Solution

Comments

Sergey Alexandrovich Kryukov 18-Oct-13 20:32pm

Why did you use something which you don't understand and which even messed up your code? You can read about Join in documentation, what's wrong with it?
—SA

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Answer 1 · 2013-10-18T14:42:00

Solution 1

Please see my comment to the question. Read about the topic: http://msdn.microsoft.com/en-us/library/system.threading.thread.join.aspx[^].

What this API does should be more than obvious from this document. How you use it is up to you. My imagination fails me when I try to figure out what could be unclear here. Perhaps you have to explain your goals or concerns, your scenario.

—SA

Posted 18-Oct-13 14:42pm

Sergey Alexandrovich Kryukov

v2

Comments

pasztorpisti 20-Oct-13 11:16am

+5, the answer is quite obvious. My experience is that "thread ownership" seems to be a quite difficult topic for most threading rookies. Since most multithreaded programs work with a fix number of threads I often recommend people to start these threads from the main, and then stop them before returning from main (before exit). A few sleeping threads don't hurt. This approach immediately suggests the usage of some higher level constructs like thread pools or message-processor threads created at program startup and these immediately hide the the usage of join. Starting and gracefully finishing threads in the middle of program execution is messy and beginners just make their own work even harder with that.

Sergey Alexandrovich Kryukov 20-Oct-13 20:42pm

I don't think "ownership" is principally difficult. Rather, this is something which is not so important, but, as thread functionality does not require tracking ownership (which means which thread has been started by which), this information may or may not be available from one or another API. In practice, this is not important, because it does not really affect thread functionality, and because the developer can distribute creation of threads in some regular and simple way, as you so reasonably advised. Even more, I often advise fixed number of thread created from the very beginning and throttled as they sleep without wasting any CPU time (blocking queue is one very regular technique) Now, join has its uses, more or less limited. If threads were created and then joined, it would defeat the parallelism...
—SA

pasztorpisti 21-Oct-13 4:14am

When I think of thread ownership I always think of the thread that actually joins the thread. :-) However in my design this is always the same thread the worker. "Thread ownership" is indeed something I use as an extra restriction because my observation is that it helps creating better design and it doesn't sacrifice any effectiveness of your threading code. Usually it doesn't make sense to create a thread on thread X and then joining it on thread Y. I often create two thread pools: One for short jobs, this pool has "num_core" number of threads. And another pool for (non-cpu-intensive) long jobs (like dir change listener). This latter "pool" runs all tasks in parallel and may have a minimum number of precreated threads (but it isnt necessary, it hides thread creation even with zero precreated threads). I never understood why do people want to put these two functionalities into one pool (cant they decide whether a job is long or short???) and this makes the pool unnecessary complicated and "undeterministic" (with a "manager thread" that tries to find out when to spawn a new thread...)

Sergey Alexandrovich Kryukov 21-Oct-13 10:28am

Joining threads it totally unrelated to their ownership. Any thread can join any other one. Joining is nothing but synchronization, the way to put some thread on conditional wait state and the wake it up. Does it make sense, for X to join Y? It depends on factors totally unrelated to ownership. For example, if X supplies data for Y, and, at the same moment, Y needs to be guaranteed that all set is ready, Y should call X.Join. As simple as that. The ownership just need not be taken in into account...
—SA

pasztorpisti 21-Oct-13 11:04am

I'm afraid we think about joining differently. Since I mostly do crossplatform programming I always use the stricter definitions and intersections of APIs. On windows it is really like any other synchronization (waitforsingleobject on a (thread) handle) followed by closing the handle but with pthread_join it is a bit different, you can (and you have to) join a (non-detached) thread exactly once and what this join does is basically like a waitforsingleobject+closehandle on windows. Of course you can still extend this interface with some extra code (for example with a condition/event + lock) to simulate the windows behavior. When I said "joining" I though of this as the last step of actually waiting/destroying the thread (with the more strict posix behavior). Of course you can put in waitable synchronization points to any point of the thread lifetime (including thread ending) but these points in my code are handled usually by events fired by the tasks/jobs executed by the specified thread. In my vocabulary thread joining is the end of the thread lifetime.

Sergey Alexandrovich Kryukov 21-Oct-13 11:17am

All right, then you are talking about something else beyond just the call to Thread.Join, but you could have it explained from the very beginning, as it's far from obvious...
—SA

pasztorpisti 21-Oct-13 11:35am

Before the .Net Thread.Join using the term "join" was a good word to make a distinction, it seems I have to find something else... :-) In my opinion joining a thread more than once is also useless and redundant feature of a threading api, every kind of threading code can be put together perfectly just by using the more strict join semantics (usually only the pool (the thread creator) has to join a thread).

Sergey Alexandrovich Kryukov 21-Oct-13 12:05pm

That's right, of course. Or, rather, I cannot imagine how a thread could be joined twice... I guess, on second time, the call will return immediately, that's it... Overall, joining thread is a rudimentary device which has too limited use, compared to the case of "permanent" threads reused "infinitely", with the use of general-purpose synchronization objects like locks and event wait handles.
—SA