-1

Say I have run a program that creates four .NET threads. Each thread takes about 45 minutes to run (on its own as a single threaded app).

Say I have access to a server with a quad-core processor. Can all four threads complete in 45 minutes?

I have done some reading from a book today, which says to take nothing for granted when it comes to multi-threading. The book seems to imply that in my example on one day could take 45 minutes because all four cores are used in parallel. However, on another day the program could take three hours (4*45) to complete.

Update The purpose of this question was to clarify a point I have read. My book implies that my program (that creates four threads and runs once a day) could use four cores on day 1 and one core on day x. I wanted to know if I have understood this correctly. I tested the program 10 times and each time all four cores were used. Therefore can I assume that all four cores will always be used?

w0051977
  • 15,099
  • 32
  • 152
  • 329
  • I'm surprised that such a low-quality question has appeared from a high-rep user. This sounds like a homework question to me that has not been researched. *It depends completely on the task being undertaken.* – AStopher Dec 07 '14 at 23:24
  • @cybermonkey, it is not a homework question. – w0051977 Dec 07 '14 at 23:33
  • Related: http://cbloomrants.blogspot.com/2010/09/09-12-10-defficiency-of-windows-multi.html , http://stackoverflow.com/questions/1579002/net-movement-of-threads-between-cores – user2864740 Dec 07 '14 at 23:50
  • @w0051977 Then please re-word it. Your question should also *really* be on Super User. – AStopher Dec 08 '14 at 09:18
  • Not only does running time depend on the tasks being undertaken, it also depends on what other programs are running on the machine at the same time, the current network traffic load (if the program communicates on the network), the current load on the database (if a database is used), and many other factors. If your threads take 45 minutes each to process, then the best you can do is to have all four threads run concurrently in 45 minutes. But it's *possible* that the four threads could take *longer* than three hours. – Jim Mischel Dec 08 '14 at 17:00

1 Answers1

2

The book is correct, in that a great many factors can conspire in the typical multi-threaded program to cause it to slow down in some or all cases. For example, careless use of locking is an excellent candidate to make programs that are never faster than on single-core, and often vastly slower. Alternatively, something as subtle as overfrequent context switching could cause massive cache pollution on all the cores, with the attendant slowdown. Basically, without actually looking at the code in detail (and preferably testing it), you just don't know.

It's not precisely the fault of the Windows kernel scheduler, either, since Linux, Hurd, Mach, and so on are not categorically better at this job to my knowledge. You can design systems that don't suffer some of these problems, but usually at the cost of binary compatibility, and often source compatibility too. Therefore, such efforts are generally confined to research OSes.

Edit: A more detailed example of cache pollution and mutex scheduler fairness is given in this presentation by Ciaran McHale.

Nathan Tuggy
  • 2,237
  • 27
  • 30
  • 38