[webkit-dev] PSA: you should use WTF::Lock and WTF::Condition instead of WTF::SpinLock, WTF::Mutex, WTF::ThreadCondition, std::mutex, std::condition_variable, or std::condition_variable_any

[Filip Pizlo]

Yes, I will need to implement some style rules!

Here's the current status of the old concurrency primitives:

ByteSpinLock and SpinLock: removed. 

Mutex and ThreadCondition: still in place because we have some code in older Safaris that expects these. I think we can remove ThreadCondition at this point, but Mutex needs to stay. Either way we should just move it out of ThreadingPrimitives and into mac/DeprecatedSymbolsUsedBySafari. 

std::mutex and friends: can't be removed, and are used by WordLock and ParkingLot internally as the fallback for making threads block. So, these will need style rules advising that you should avoid them. 

We should probably also put some thought into what styles of locking we should use now that we have more flexibility. For example, it would be pretty cheap to give Lock the ability to support assertHeldByThisThread and recursive locking. We should decide if we want to use the std:: lock guards or our own. Condition::notifyAll benchmarks as fast as Condition::notifyOne in all but pathological cases so it's not obvious that we need the latter. Finally, the advice that you should notify after releasing a lock doesn't really apply to our locks so we could mandate that the lock is held when you notify, since that's a cheap way of enforcing that you don't have a notify race. I think it would be great to making locking even easier and I'm curious what others think!

-Filip

> On Aug 22, 2015, at 2:46 PM, Darin Adler <darin at apple.com> wrote:
> 
> Even if we remove the obsolete WTF classes, we might still want a checker rule about the ones in the std namespace.
> 
> — Darin
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev