WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Details
Formatted Diff
Diff
Patch
(5.10 KB, patch)
2011-02-10 17:41 PST
,
Daniel Bates
ap
: review-
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Daniel Bates
Comment 1
2011-02-10 17:15:47 PST
Created
attachment 82074
[details]
Patch
Daniel Bates
Comment 2
2011-02-10 17:41:08 PST
Created
attachment 82077
[details]
Patch
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.
Top of Page
Format For Printing
XML
Clone This Bug