0

For example:

pthread_mutex_lock();
//Do something
sleep(1);                //causes issues waiting while holding lock

pthread_mutex_unlock();

what is the solution if we don't want to use sleep inside mutex lock

Ganesh Naik
  • 11
  • 1
  • 2
  • A language issue from my side perhaps, but what is a "*coverity issues*"? – alk Aug 20 '18 at 10:58
  • 5
    The solution is to not sleep. – tkausl Aug 20 '18 at 10:58
  • @alk I think that one: https://scan.coverity.com/ https://en.wikipedia.org/wiki/Coverity – hellow Aug 20 '18 at 11:01
  • 8
    A better question would be "Why would anyone be calling sleep() inside a mutex lock". I have absolutely no idea why anyone would do that. – Lundin Aug 20 '18 at 11:04
  • 2
    To answer this question completely, we need to know why you were calling sleep() while holding a lock in the first place. – zwol Aug 20 '18 at 11:07
  • 3
    I've written a lot of multithreaded apps over decades, and I can't rememeber all the design details, but I'm 100% sure that I have never called Sleep() inside a lock. – Martin James Aug 20 '18 at 11:20
  • 2
    The most likely reason he is calling sleep is to make sure that the mutex is held for an appreciable time so he can see how the mutex works/check the lock is working. It's not unusual to call `sleep` in a test case for example if you want to test what happens if something takes longer than expected. – Ben Aug 20 '18 at 11:54
  • @Ben Why would you use a static analyser on your lab/test/junk code though? Such tools should only be used on production quality code (unless one loves to waste time chasing non-issues). – Lundin Aug 20 '18 at 12:54
  • @Lundin He's obviously a beginner, as we all once were. The answer for him is to ignore this warning or use a pragma or exclusion list to disable it. He's sleeping in a mutex because he is learning about mutexes, and he's running coverity on it because he is learning about coverity. There is no mystery here. – Ben Aug 20 '18 at 13:08
  • @Ben If you say so. I can't read the OP's mind so I'll refrain from guessing the reasons why. – Lundin Aug 20 '18 at 13:21
  • It is calling sleep because it is waiting for database to be ready. consider it like: mutex_lock() fun1() //calling fun1() mutex_unlock() fun1() { do { e = sql_db_ready() wait() cnt++; }while(cnt < 10); – Ganesh Naik Aug 20 '18 at 14:57
  • In above comment , fun1() contains wait() which is sleep() for 1 seconds – Ganesh Naik Aug 20 '18 at 15:04
  • 1
    I think there are better ways to wait for an event. This looks like an XY problem. – Tim Randall Aug 20 '18 at 15:06
  • Is there any way to avoid sleep in this scenario? or do i have to use pthread_cond_wait instead of sleep – Ganesh Naik Aug 20 '18 at 17:03
  • @GaneshNaik There ought to be a better way to wait for the db to be ready than a check-and-sleep loop, but that's not important right now; for purpose of this question, what I still need to know is, why does this lock need to be held while you wait for the db? What other concurrent operation could you be racing with if you didn't hold the lock? – zwol Aug 20 '18 at 18:46

1 Answers1

7

As a rule of thumb, you usually (but not always) don't want to hold a mutex for a long period of time (otherwise, other threads locking the same mutex would wait too long), and a full second is a long period for a processor doing billions of elementary operations each second.

You might want to use condition variables (since pthread_cond_wait is atomically releasing the mutex), or do the sleep (or some poll(2)...) outside of the locked region. You might even -on Linux- use pipe(7)-s -or the cheaper but Linux-specific eventfd(2)- to communicate between threads running event loops.

The coverity static source analyzer is heuristic and might give false alarms.

Take time to read a good Pthread tutorial.

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547