0

This is an exam question (practice exam, not the real one). It's about concurrent programming using a multi-core processor and the problems with using locks.

"In concurrent programming is it possible that, by using locks, a program might sometimes use more processors than are necessary?"

In other words, is this ever possible? It's a true/false question. I can't find an answer anywhere and I'm revising for my exams.

user3666197
  • 1
  • 6
  • 50
  • 92
  • 1
    Ugly question! What does "more processors than are necessary" actually mean? And, to what are we supposed to compare this program? The same program but with the locks simply commented out? IMO, The only _right_ answer is going to be the one that's printed in the textbook or, was given to you in a lecture. Hope you took good notes! – Solomon Slow Dec 16 '20 at 20:29
  • Hi Solomon, sadly there are many questions that are not covered in the lectures, I am particularly diligent with detailed notes on all my lectures and given Covid, I have every single lecture video to hand to replay (and I have!). This just isn't covered and nor can I find anything similar to help me when Googling. We haven't done concurrent programming yet (first year), so this is all theoretical, which makes it harder. So I guess the main question is: is it ever possible that more processors are used, even if it's only occasionally? I guess comparison could be with the locks commented out. – theWhiteKnight Dec 16 '20 at 20:49
  • A [CONCURENT]-flow of processes is by far not the same as [PARALLEL]-process orchestration - even if professors tell you. Pick a better professor if they still do... Locks are "blocking"-instrumentation, that "enforces" some sort of inter-dependency ( weaker or stronger thought off - whereas some other design-side minds, like CSP-based process-dependency concepts may warrant a non-deadlockin right-enough pair-wsie blocking to happen where needed and as needed and nothing more to ever happen, that would introduce a need for more than needed resources to be used for a process-scheme to flow ... – user3666197 Dec 16 '20 at 21:36
  • Re, "...comparison...with the locks commented out." But if you simply commented out the locks, then the program would not work correctly any more. So, if the working version uses more CPUs than the non-working version, wouldn't those extra CPUs be "necessary?" On the other hand, If we want compare the version that uses locks to a _different algorithm_ that is able to correctly do the same job, but without using locks; then I don't see how we can directly compare them. Can't really know how many CPUs either of them will use without knowing the details of the two algorithms. – Solomon Slow Dec 16 '20 at 21:36
  • You might like to re-read this: https://stackoverflow.com/tags/concurrent-processing/info and confront that with this: https://stackoverflow.com/revisions/8337936/4 and other hidden costs related to the Amdahl's argument - https://stackoverflow.com/questions/65178416/negative-speed-up-in-amdahls-law – user3666197 Dec 16 '20 at 21:40
  • Hi Solomon, that's really interesting because it's all about the problems with locks so I guess that if you can write a different alogithm without locks that does the same job and uses fewer processors then the answer is that one of the problems with locks is that they can sometimes cause you to use more processors (than the non-lock algorithm). Once I start concurrent programming, I guess I will understand this better, that module is next term. Thanks for taking the time to answer a beginner! – theWhiteKnight Dec 16 '20 at 22:13

2 Answers2

0

The concurrent program with N threads of execution using locks at any point in time can have M=0 .. N-1 threads waiting for locks; thus this program can only be utilizing N-M processors since waiting for a lock does not require a processor. Thus, no, using locks does not increase the number of processors required by a concurrent program.

mevets
  • 10,070
  • 1
  • 21
  • 33
0

With an efficient implementation of multi-threading and locks, if a thread blocks waiting for a lock for any significant time, the scheduler / lock implementation will reassign the core to do something else.

But since the exam question is asking if it is ever possible to use more processors than are strictly necessary, the answer is that it depends on the implementation of threads / locks / scheduling. For instance, there is a kind of lock called a spinlock where the lock implementation does NOT surrender control of the processor while waiting to acquire a lock. Instead, it polls the lock in a tight loop trying to acquire it.

Why would you do that? Well, if the lock is likely to become available in a short enough period of time, then the CPU wasted "spinning" on the lock is less than would be spent on performing a full context switch.

So I don't think your exam question has a simple yes / no answer.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216