31–40 of 42 posts
Random observation: WTF would be a great base exception in a new, hip programming language. WTF.happened WTF.context ...and so on
Not a good idea, because now you cannot easily grep anymore for "WTF" in source code comments :)
All the JetBrains tools do this AFAIK.
WebKit has its own lock and malloc implementations and many other redoes of standard library. Given that Apple's engineers have a great deal of influence on all of WebKit, libc++ and their operating systems, I wonder why they do not port those WebKit implementations onto OS X and iOS.
Earlier quoted context omitted.
race conditions > Textbooks will tell you that if you always lock in the same order, you will never get this kind of deadlock. Practice will tell you that this approach doesn't scale: when I create a new lock, I don't understand enough of the kernel to figure out where in the 5000 lock hierarchy it will fit. https://www.kernel.org/pub/linux/kernel/people/rusty/kernel-...
Only that lock-free (or wait free, or even obstruction-free) datastructures aren't exactly trivial to implement correctly either. Besides often having architectural impact (Uh, Oh, I now need to declare quiescent periods?), they're extremely hard to debug, and there's even less automated verification than for locking.
That made me smile. It's nice to see some playfulness in business.
Packing several unrelated, highly contended mutexes into the same 32 bit word is probably not a good idea, though. :)
This reminds me of early Unix and its "wait channels", which were just addresses, not even objects. A process could wait, specifying the address of any object whatsoever as a "channel". A wakeup for that address would resume it. This required no storage in the addressed object itself; the extra paraphernalia required for it was associated by a hash or whatever. And of course that paraphernalia is transient; an object that nobody is waiting on doesn't need it.
Spinning in locks are always tricky business. The sharpest thorn, to me, is: what happens when you are running inside the critical section and your thread gets preempted? Well, now the next thread which tries to acquire the lock is stuck waiting. But waiting for what? Waiting for the original thread to get scheduled. Now, the OS has no idea that the original thread should get scheduled again and is free to continue s…
http://stackoverflow.com/questions/19863734/what-is-pthread-...
The idea is to avoid spinning using hard-coded constants, but put a modicum of on-the-fly empirical science into it: measure the duration of the critical regions with a smoothed estimator, which is maintained in the mutex. If the actual wait exceeds this smoothed average by too much (say double) then conclude that the owner must be pre-empted and break the spin with rescheduling.
The smoothing is done very easily using a few bit operations that implement an IIR filter, similarly to the TCP RTO estimator.
Earlier quoted context omitted.
Only that lock-free (or wait free, or even obstruction-free) datastructures aren't exactly trivial to implement correctly either. Besides often having architectural impact (Uh, Oh, I now need to declare quiescent periods?), they're extremely hard to debug, and there's even less automated verification than for locking.
there are many design alternatives to locking. Lock-free synchronization is one of them, but queueing is another. The best alternative is to simplify your control flow so that you don't need as much synchronization.
Please replace the very slow Mac OS X pthread_mutex locks with the WTF::Lock implementation to benefit all applications. I can live with it still being 64 bytes and the scheduling being not completely fair. The OS X pthread mutexes are several times slower than Linux on the same hardware.
I very very much doubt that linux implementation is that different (I'm actually fairly confident pthread_mutex on linux and OS X El Capitan+ are mostly on par)
Two things come to mind when reading this: 1. WTF::Lock is using sequential consistency for all of the slow path operations. Surely this isn't necessary and it could still use acquire/release for most of them (like it does in the fast path). 2. Ditching OS-provided mutexes has one possibly-important drawback on OS X and iOS: lack of priority donation. Recent versions of OS X and iOS have a Quality Of Service implemen…
Weakening the consistency of operations on the slow path is not going to be a speed-up. Those paths are not dominated by pipeline effects inside the CPU. They are dominated by context switches and memory contention. So, SC is exactly right: it's harder to get wrong and exactly the same speed. It's true that WTF::Lock doesn't support priority inheritance. That's fine for WebKit's threads.
Also on a contended lock, there's a very strong possibility that you will decide that the lock can be taken right before you block.
On intel of course, it doesn't matter.