[Webkit-unassigned] [Bug 181161] New: [WTF] Use std::mutex and std::condition_variable for the lowest level locking primitives

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=181161

            Bug ID: 181161
           Summary: [WTF] Use std::mutex and std::condition_variable for
                    the lowest level locking primitives
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: utatane.tea at gmail.com

We construct our WTF::Lock and WTF::Condition based on ParkingLot. And ParkingLot depends on the platform mutex and condition variable, which are WTF::Mutex and WTF::ThreadCondition.
WTF::Mutex is implemented in pthread_mutex_t in POSIX, and CRITICAL_SECTION in Windows.
But I don't think we should maintain these platform-specific WTF::Mutex and WTF::ThreadCondition. We should use C++ std::mutex and std::condition_variable.
They offer several benefits

1. We can remove bunch of code creating WTF::Mutex and WTF::ThreadCondition. We can just use std::mutex and std::condition_variable directly.

2. Implementation quality is improved by the platform libraries.
In POSIX environment + LLVM libc++, std::mutex is implemented with pthread_mutex_t. And std::condition_variable is implemented by pthread_cond_t.
So there are no implementation difference. In Windows, std::mutex is implemented with SRW lock. So it offers better performance than CRITICAL_SECTION[1,2].

3. We can clearly state that WTF::Lock and WTF::Condition are preferred ones. When we have WTF::Mutex and WTF::Lock, it is a bit unclear that which one is better since both are in WTF.
But if we have std::mutex and WTF::Lock, we can easily know that WTF::Lock is better one since we additionally have this one in WTF.

[1]: https://stackoverflow.com/questions/9997473/stdmutex-performance-compared-to-win32-critical-section
[2]: https://msdn.microsoft.com/library/windows/desktop/aa904937(v=vs.85).aspx

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20171226/e21d70c4/attachment.html>