RESOLVED INVALID 54258
Make class Mutex work for Pthreads implementation with recursive mutexes
https://bugs.webkit.org/show_bug.cgi?id=54258
Summary Make class Mutex work for Pthreads implementation with recursive mutexes
Daniel Bates
Reported 2011-02-10 17:02:04 PST
Some Pthreads implementations may not support non-recursive mutexes (i.e. mutex type PTHREAD_MUTEX_NORMAL). For systems with such an implementation we should make the class Mutex mimic the behavior it has when compiled on systems that have a Pthreads implementation that support mutex type PTHREAD_MUTEX_NORMAL.
Attachments
Patch (4.28 KB, patch)
2011-02-10 17:15 PST, Daniel Bates
no flags
Patch (5.10 KB, patch)
2011-02-10 17:41 PST, Daniel Bates
ap: review-
Daniel Bates
Comment 1 2011-02-10 17:15:47 PST
Daniel Bates
Comment 2 2011-02-10 17:41:08 PST
WebKit Review Bot
Comment 3 2011-02-10 17:42:49 PST
Attachment 82077 [details] did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/JavaScriptCore/ChangeLog', u'Source..." exit_code: 1 Source/JavaScriptCore/wtf/ThreadingPthreads.cpp:389: Tests for true/false, null/non-null, and zero/non-zero should all be done without equality comparisons. [readability/comparison_to_zero] [5] Total errors found: 1 in 4 files If any of these errors are false positives, please file a bug against check-webkit-style.
Daniel Bates
Comment 4 2011-02-10 17:52:14 PST
(In reply to comment #3) > Attachment 82077 [details] did not pass style-queue: > [...] > Source/JavaScriptCore/wtf/ThreadingPthreads.cpp:389: Tests for true/false, null/non-null, and zero/non-zero should all be done without equality comparisons. [readability/comparison_to_zero] [5] > Total errors found: 1 in 4 files On success pthread_cond_timedwait() explicitly returns 0. I thought to preserve this explicit mention of 0. I can change code to read "return !pthread_cond_timedwait(...)".
Alexey Proskuryakov
Comment 5 2011-02-10 20:16:26 PST
Comment on attachment 82077 [details] Patch I think that this has race conditions in updating m_recursionCount. In unlock(), you decrease the count after unlocking, but another thread can already take this mutex, and be increasing the count. pthread_cond_wait() temporarily releases the mutex - should the count be decreased, too? Following tryLock() was just too difficult for me. Can you name the platform this is needed for? Can a proper mutex be added to its pthreads implementation instead?
Daniel Bates
Comment 6 2011-11-07 20:50:30 PST
A proper mutex was added to the pthreads implementation for the platform.
Note You need to log in before you can comment on or make changes to this bug.