Self-Managed Threads or Thread Pool?

Sign in to answer this question.

• K

  KaktusJack15y agoPosted Jun 20, 2011, 2:37 AM

  Oh my! "MSDN" eeekkkk!! To me that's like reading legal/insurance documents, they all just go over my head. But from what I've gathered like you said that the STAThread doesn't even have to be there which I didn't think it did but I just haven't tried to figure out why it was. But I thank you for the link, I do understand multi-threading a bit more now.
  
• 

  Vulpes15y agoPosted Jun 16, 2011, 5:11 AM

  Well, first of all, if you only have one processor or core, then using multi-threading doesn't speed things up. If anything it slows them down slightly because of the time needed to set up a new thread, create a stack for it etc. and for the OS to perform 'context switches' between the threads.

  
  

  It may appear that it's speeding things up in a GUI application because, if you don't use more than one thread, the GUI will be frozen whilst waiting for some long running operation to complete.

  
  

  However, if you have multiple processors or cores, then you can have true 'concurrency' and broadly speaking the time taken to perform certain types of operation (basically those that can be easily split up into separate tasks) will be inversely proportional to the number of cores.

  
  

  So, if Nero is taking 3 hours to make a DVD compilation on a single core machine and 1.5 hours to do it on a dual core machine, then it must be making use of the cores and running at least one thread on each core.

  
  

  Incidentally, the STAThread attribute which VS adds by default to your Main() method is concerned with the COM apartment threading model - STA is single thread and MTA is multiple thread - and is nothing to do with multiple cores as such. Suffice it to say that a Windows Forms application needs to run under STA otherwise it may not work correctly. However, if you need to know more, check out (http://msdn.microsoft.com/en-us/library/ms693344(VS.85).aspx).

  
  

  Although I'm no expert on either compression or encryption, I'd have thought that the techniques used would lend themselves to being split over multiple cores. However, if you were recombining the results into a single file, then you'd need some way of determining the 'joins' so you could decompress or decrypt the file using the same partitions. If you didn't do this, then it might not work correctly. 
• K

  KaktusJack15y agoPosted Jun 15, 2011, 11:06 PM

  @Vulpes:
  
  Good day to you!! Haven't spoken with you in awhile!
  
  So if I have a [STAThread] it is/will only run on 1 core at a time and the OS wont switch the cores during the interupt process? (not that it matters much)
  And I'm not to certain about Nero splitting up the thread(s) because when you start the DVD conversion it has to do all the processing to convert it which means, with your suggestion, that isn't possible. Again I haven't a big clue about multi-threading but logic says that "convert movie.avi to movie.vob and such" has 1 long process. Only thing I can think of is that it has a different thread for each .vob file or something. Would love any ideas people would have as to narrow this down a bit. Another example would be what if I was zipping and then encrypting a big file, say 1.75GB. How could I use multi-cores to do the job in less time?
  
  Thanks again Vulpes as always,
  {KJ}
  
• 

  Vulpes15y agoPosted Jun 15, 2011, 6:02 AM

  Well, a thread can only be assigned to a single processor or core at any one time i.e. it cannot transition between cores.

   

  So, the answer to your question is that the OS is distributing the workload between cores by assigning a thread or threads on each of those cores to do part of the work.

  
  

  Although I don't know for sure, I'd imagine that a commercial program such as Nero does use some sort of threadpool mechanism as this is generally the best approach for writing 'divide and conquer' algorithms across multiple threads or cores.