0

How to answer this? please help.

Consider the following program with 3 threads.

locks l1, l2, l3;

*Thread 1

while(1){

l1.lock();

l2.lock();

printf(“Red”);

l3.unlock();

l1.unlock();}

*Thread 2

while(1){

l2.lock();

l3.lock();

printf(“Green”);

l1.unlock();

l2.unlock();}

*Thread 3

while(1){

l3.lock();

l1.lock();

printf(“Blue”);

l2.unlock();

l3.unlock();}

a) What are the possible outcomes of the above program. Can you explain how this'll happen? b) Will this code lead to a deadlock?

hukana pakaya
  • 1
  • 5
  • Locks is an abtract concept, but can you specify the definition of your type: 'locks'?; this maybe can be usefull http://stackoverflow.com/questions/9382122/whats-the-difference-between-mutex-and-lock – Rama Dec 03 '16 at 13:09

2 Answers2

1

It depends on what l1.lock(), l1.unlock(), etc., actually do. Since this is tagged C++ (although the title says C), if these function calls are managing std::mutex objects, the result is undefined behavior, with each thread unlocking a mutex that it didn't lock.

Pete Becker
  • 74,985
  • 8
  • 76
  • 165
  • sorry since im actually very much new to these.so can you explain those for me a bit more please? – hukana pakaya Dec 03 '16 at 12:38
  • The rule for mutexes in C++ is that the only thread that's allowed to unlock a mutex is the one that locked it. But since you've already accepted another answer, I don't see any point in further discussion. – Pete Becker Dec 03 '16 at 12:44
  • I don't know what you meant by accepted another answer. Im new to here.but anyway it'll be very helpful if you can further explain please – hukana pakaya Dec 03 '16 at 13:42
  • That green checkmark (that you've now removed) means you accepted the answer as the right solution to the problem. – Pete Becker Dec 03 '16 at 13:44
0

For the sake of readibly, I'll refer to locks as an array (eg. lock[0], lock[1], lock[2])

A) Depends on which thread starts executing first.

  1. If thread 1 starts first: Red, Blue, Green, Red, Blue, ...
  2. If thread 2 starts first: Blue, Green, Red, Blue, Green, ...
  3. If thread 3 starts first: Green, Red, Blue, Green, Red, ...

B) Yes, it can. And it probably will. Consider it:

  1. Thread 1 locks lock[0]
  2. Thread 2 locks lock[1]
  3. Thread 3 locks lock[2]
  4. Thread 1 try to lock lock[1], waiting for thread 2
  5. Thread 2 try to lock lock[2], waiting for thread 3
  6. Thread 3 try to lock lock[3], waiting for thread 1
quartzsaber
  • 174
  • 3
  • 10
  • can you explain how it can switch between threads? im not clear on it – hukana pakaya Dec 03 '16 at 12:36
  • On real computers, it can appear completely random as it completely depends on scheduler (which is usually part of the OS). There's really nothing more to say, since nowdays computers are multicore, which means threads would actually run parallel. – quartzsaber Dec 04 '16 at 13:39
  • For further reading, I would suggest Wikipedia – quartzsaber Dec 04 '16 at 13:40
  • its too much :( need specifically answer for this – hukana pakaya Dec 04 '16 at 16:38
  • Like I said, you should consider that threads are impossible to predict - it can execute pretty much anytime as long as it's alive. For example, your code may or may not catch itself inside a deadlock, because if your OS decides to switch threads every loop (of your code), it works normally. But if OS switches thread while a thread has locked only one mutex, it will cause deadlock. (to solve this problem, you need to insert a global mutex that surrounds locking two mutexes) – quartzsaber Dec 05 '16 at 12:21