General threading question
-
Can't believe I am asking this, and I admit I am lazy right now... I just have not had the chance to look into it or test it yet today so I figured I would throw it out there and see what folks have to say... By the way, I am interested in this even in non-dot-net based languages, but didn't want to cross post :) When you fire up a list of threads are they always guaranteed to REALL fire up in the order that you start them in or could the scheduler for some reason decide to place one above another, keeping in mind that for my contrived example they all are the same code that is... Just wondering if anyone has ever tried this and seen odd results, or at least results that made them go hmmm for a second... My assumption is hat the process of starting a thread is sync so they are always going to get started in the same order, no matter what goes on in the startup code of the thread procedure you are kicking off, but I honestly have not payed that close attention before and can't remember ever wondering\caring.... Just came to my head right now and figured I would ask....
-
Can't believe I am asking this, and I admit I am lazy right now... I just have not had the chance to look into it or test it yet today so I figured I would throw it out there and see what folks have to say... By the way, I am interested in this even in non-dot-net based languages, but didn't want to cross post :) When you fire up a list of threads are they always guaranteed to REALL fire up in the order that you start them in or could the scheduler for some reason decide to place one above another, keeping in mind that for my contrived example they all are the same code that is... Just wondering if anyone has ever tried this and seen odd results, or at least results that made them go hmmm for a second... My assumption is hat the process of starting a thread is sync so they are always going to get started in the same order, no matter what goes on in the startup code of the thread procedure you are kicking off, but I honestly have not payed that close attention before and can't remember ever wondering\caring.... Just came to my head right now and figured I would ask....
Ray Cassick wrote:
I am lazy right now
I'm not in a habit of answering lazy questions, I'll keep it short: nothing is guaranteed. A managed thread is as much as "a job that could be executed independently of other jobs within the same process", which means it needs synchronization if other threads are to produce data it needs or consume data it generates, and which also means it does not even have to map onto a "physical" thread. Yes, a new Thread instance may or may not imply a new thread (at least so says the doc, I haven't ever noticed any of this). And unmanaged threads will be scheduled by the (Windows) kernel as it sees fit, based on CPU activity, thread readiness, thread priority, some fairness measures, and the like. And particularly in Windows with a minimum of guarantees. Starting a thread is like double-clicking an EXE file: it will eventually cause something to happen. There clearly must be a more overall question, however you forgot to ask it I'm afraid. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
-
Can't believe I am asking this, and I admit I am lazy right now... I just have not had the chance to look into it or test it yet today so I figured I would throw it out there and see what folks have to say... By the way, I am interested in this even in non-dot-net based languages, but didn't want to cross post :) When you fire up a list of threads are they always guaranteed to REALL fire up in the order that you start them in or could the scheduler for some reason decide to place one above another, keeping in mind that for my contrived example they all are the same code that is... Just wondering if anyone has ever tried this and seen odd results, or at least results that made them go hmmm for a second... My assumption is hat the process of starting a thread is sync so they are always going to get started in the same order, no matter what goes on in the startup code of the thread procedure you are kicking off, but I honestly have not payed that close attention before and can't remember ever wondering\caring.... Just came to my head right now and figured I would ask....
It probably gets even crazier in .Net 3 and above as managed threads are generally serviced by a central threadPool, and you just get the next one to stick up it's hand and admit to not doing any work at the moment. It will then start when it is ready. If the pool is empty the framework just extends the pool, calls a party and a whole load more threads become available... Not unlike the highfliers of the hollywood party scene.
If you have knowledge, let others light their candles at it. Margaret Fuller (1810 - 1850) [My Articles] [My Website]
-
It probably gets even crazier in .Net 3 and above as managed threads are generally serviced by a central threadPool, and you just get the next one to stick up it's hand and admit to not doing any work at the moment. It will then start when it is ready. If the pool is empty the framework just extends the pool, calls a party and a whole load more threads become available... Not unlike the highfliers of the hollywood party scene.
If you have knowledge, let others light their candles at it. Margaret Fuller (1810 - 1850) [My Articles] [My Website]
Did that actually happen in 3.0? I was under the impression 3.0 and 3.5 didn't change anything to what already existed in 2.0, it just added functionality. It would be more likely to hold true since 4.0 but I haven't observed (nor tested or analyzed) these aspects, I just have known all along it was going to happen someday, as it is in MSDN doc since day 1. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
-
Did that actually happen in 3.0? I was under the impression 3.0 and 3.5 didn't change anything to what already existed in 2.0, it just added functionality. It would be more likely to hold true since 4.0 but I haven't observed (nor tested or analyzed) these aspects, I just have known all along it was going to happen someday, as it is in MSDN doc since day 1. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
Depends. 3.0 introduced the ThreadPool but you could still do it the same old way if you wanted. Not sure about 4.0.
If you have knowledge, let others light their candles at it. Margaret Fuller (1810 - 1850) [My Articles] [My Website]
-
Can't believe I am asking this, and I admit I am lazy right now... I just have not had the chance to look into it or test it yet today so I figured I would throw it out there and see what folks have to say... By the way, I am interested in this even in non-dot-net based languages, but didn't want to cross post :) When you fire up a list of threads are they always guaranteed to REALL fire up in the order that you start them in or could the scheduler for some reason decide to place one above another, keeping in mind that for my contrived example they all are the same code that is... Just wondering if anyone has ever tried this and seen odd results, or at least results that made them go hmmm for a second... My assumption is hat the process of starting a thread is sync so they are always going to get started in the same order, no matter what goes on in the startup code of the thread procedure you are kicking off, but I honestly have not payed that close attention before and can't remember ever wondering\caring.... Just came to my head right now and figured I would ask....
Threads can be expected to start and threads can be expected to stop(maybe). All other assumptions are not thread safe.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
-
Threads can be expected to start and threads can be expected to stop(maybe). All other assumptions are not thread safe.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
Yeah, I figured... and honestly I am not surprised, especially now days with the progression from simple clock allocation over to physical core style allocation. Just makes me wonder if REAL multi-threading, outside of the typical ‘I just want to be able to do a few things at a time to help increase efficiency’ is really used today except for some very time-critical systems.