Multithreading done "right"
-
The only reason I can imagine doing something like that is if there is a requirement that
GenerateTimeLineImage()execute on a non-UI thread, and yet be synchronized to the UI thread that requests the operation. There are plenty of the opposite circumstance (requesting a UI operation from a worker thread), but this sounds strange.Software Zen:
delete this;Or perhaps to protect the UI thread from Exceptions? :confused:
-
Or perhaps to protect the UI thread from Exceptions? :confused:
Or perhaps there is another thread that somehow manages these extra threads (e.g., abort them if they take too long).
-
Or perhaps there is another thread that somehow manages these extra threads (e.g., abort them if they take too long).
-
Or perhaps to protect the UI thread from Exceptions? :confused:
-
I recently started working for a new company and found quite a few situations like this:
Thread m_thread = new Thread(new ThreadStart(GenerateTimeLineImage));
m_thread.Start();
m_thread.Join();I'm no expert on mulithreading but there are so many different (not just brainless copy-paste) of code like that, that it made me wondering is there some hidden magic behind that code that I'm not aware of. So, what's the difference between that and
GenerateTimeLineImage();
besides obvious performance loss due to creating a pointless thread?
Call me a nice guy who generally gives people the benefit of the doubt, but this looks like code where someone INTENDED for some operations to occur on separate threads asynchronously, put some of the plumbing in, put a thread.join in for synchronous debugging, and never got back to it. You are correct in that the code would be more performant without creating the additional thread as they presently are, but the context of the usage is also important in determining your predecessor's intent. If GenerateTimeLineImage() is a void function that is basically a "fire and forget" service call, commenting out m_thread.Join() might increase application performance, and by quite a bit. I'll tell you that there is no hidden magic, but you haven't provided enough context for me to be as condemning as some other folks here.
-
Or perhaps to protect the UI thread from Exceptions? :confused:
PIEBALDconsult wrote:
Or perhaps to protect the UI thread from Exceptions?
I suspect that would probably be a misunderstanding of exceptions. If the thread code doesn't catch exceptions then it will terminate the application, thus certainly impacting the UI. And if it does catch exceptions then just the same as wrapping the method call in a try/catch.
-
Call me a nice guy who generally gives people the benefit of the doubt, but this looks like code where someone INTENDED for some operations to occur on separate threads asynchronously, put some of the plumbing in, put a thread.join in for synchronous debugging, and never got back to it. You are correct in that the code would be more performant without creating the additional thread as they presently are, but the context of the usage is also important in determining your predecessor's intent. If GenerateTimeLineImage() is a void function that is basically a "fire and forget" service call, commenting out m_thread.Join() might increase application performance, and by quite a bit. I'll tell you that there is no hidden magic, but you haven't provided enough context for me to be as condemning as some other folks here.
Member 7679313 wrote:
Call me a nice guy who generally gives people the benefit of the doubt, but this looks like code where someone INTENDED for some operations to occur on separate threads asynchronously, put some of the plumbing in, put a thread.join in for synchronous debugging, and never got back to it.
Ok, I call you a nice guy :) He did write that he found this in serveral places in the code, wich makes some kind of accident less likely. I would just take a look at some other projects he worked on and if something like that also appears there, then there is little room left for doubt.
At least artificial intelligence already is superior to natural stupidity
-
I recently started working for a new company and found quite a few situations like this:
Thread m_thread = new Thread(new ThreadStart(GenerateTimeLineImage));
m_thread.Start();
m_thread.Join();I'm no expert on mulithreading but there are so many different (not just brainless copy-paste) of code like that, that it made me wondering is there some hidden magic behind that code that I'm not aware of. So, what's the difference between that and
GenerateTimeLineImage();
besides obvious performance loss due to creating a pointless thread?
-
He's not, I'm his replacement... :)
-
I recently started working for a new company and found quite a few situations like this:
Thread m_thread = new Thread(new ThreadStart(GenerateTimeLineImage));
m_thread.Start();
m_thread.Join();I'm no expert on mulithreading but there are so many different (not just brainless copy-paste) of code like that, that it made me wondering is there some hidden magic behind that code that I'm not aware of. So, what's the difference between that and
GenerateTimeLineImage();
besides obvious performance loss due to creating a pointless thread?
If there's version control in place, have a look - it might be that previous versions had some code between .Start() and .Join().