A Gentle Introduction to Multithreading • Hacker News Board

Re: A Gentle Introduction to Multithreading

#11

Post by pjc50 » Tue, Mar 12, 2019, 10:31 AM UTC

Lerc wrote: post #4

renholder wrote: post #3

> it is not 100% guaranteed that threads will perform their operations truly in parallel, that is at the same time: it really depends on the underlying hardware. I thought it really depended on a lot of factors, most predominantly thread scheduling (based on thread priority)[0]? [0] - https://docs.microsoft.com/en-us/windows/desktop/ProcThread/...

Are there any operating systems that let you explicitly run CPUs in parallel? I'm thinking n threads where the process requests the operating system scheduler to start and stop them all at the same time. Of course the OS would be permitted to refuse if it wasn't capable (or just not allowed). A synchronised cpu master-slave relationship could be beneficial to parallelize some of the middle ground between instruction…

Why would you want to override the scheduler like that? That would also mean not scheduling your process until all the CPUs were clear, and greatly increasing scheduler coordination overhead. So it would decrease overall work throughput.

CPU affinity is genuinely useful, but I can't see why you'd want this kind of temporal affinity. Especially since you could have different CPUs running at different speeds!

Re: A Gentle Introduction to Multithreading

#12

Post by known » Tue, Mar 12, 2019, 10:55 AM UTC

Please note that

  Application can allocate memory. 
  Application cannot allocate CPU; 
  OS does that;

Re: A Gentle Introduction to Multithreading

#13

Post by znpy » Tue, Mar 12, 2019, 11:17 AM UTC

amelius wrote: post #9

Is there a good overview of different concurrency/parallelism models and related abstractions somewhere?

Seven Concurrency Models in Seven Weeks: https://pragprog.com/book/pb7con/seven-concurrency-models-in...

Re: A Gentle Introduction to Multithreading

#14

Post by kjeetgill » Tue, Mar 12, 2019, 2:51 PM UTC

Lerc wrote: post #4

renholder wrote: post #3

> it is not 100% guaranteed that threads will perform their operations truly in parallel, that is at the same time: it really depends on the underlying hardware. I thought it really depended on a lot of factors, most predominantly thread scheduling (based on thread priority)[0]? [0] - https://docs.microsoft.com/en-us/windows/desktop/ProcThread/...

Are there any operating systems that let you explicitly run CPUs in parallel? I'm thinking n threads where the process requests the operating system scheduler to start and stop them all at the same time. Of course the OS would be permitted to refuse if it wasn't capable (or just not allowed). A synchronised cpu master-slave relationship could be beneficial to parallelize some of the middle ground between instruction…

You can get that effect by pinning processors to threads and you can do the sync yourself with a barrier (like Java CyclicBarrier, not a memory barrier.)

Re: A Gentle Introduction to Multithreading

#15

Post by sliken » Wed, Mar 13, 2019, 1:32 AM UTC

quietbritishjim wrote: post #7

renholder wrote: post #3

> it is not 100% guaranteed that threads will perform their operations truly in parallel, that is at the same time: it really depends on the underlying hardware. I thought it really depended on a lot of factors, most predominantly thread scheduling (based on thread priority)[0]? [0] - https://docs.microsoft.com/en-us/windows/desktop/ProcThread/...

It depends on a lot of factors, but if your CPU physically does not have multiple cores then you can be 100% sure that your threads will not be executing code literally in parallel. I think on most operating systems, if you have a multicore CPU and very little load apart from your program, and you run CPU-bound code in multiple threads, then you will see those threads executing in parallel in different cores.

SMT (Like Intel's hyperthreading) can actually run 2 different instructions from 2 different processes in the same clock cycle on a single core.