That’s cool but calling names isn’t a point...
-
This Tweet is unavailable.
-
-
This Tweet is unavailable.
-
Replying to @Jonathan_Blow @kalin_t
Why not? To me the contract of a "pipe" is inherently non-blocking, and trying to build a nonblocking pipe on top of mutexes is a risky endeavor. Of course it's possible but there's no downside to using a bug-free existing queue, while writing your own is pretty risky.
0 replies 0 retweets 2 likes -
This Tweet is unavailable.
-
This Tweet is unavailable.
-
The phrase "lock-free" is the problem here, and it should probably be banished. The correct phrase is "wait-free", as in http://cs.brown.edu/~mph/Herlihy91/p124-herlihy.pdf …, and that has nothing to do with whether or not you implement it with a "mutex".
2 replies 0 retweets 7 likes -
Replying to @cmuratori @Jonathan_Blow and
The phrase "lock-free" makes it sound like nobody is holding a mutex because they didn't physically issue the mutex in their code. But that is false. The CPU core _is_ taking the mutex, via MESI, unless you are literally talking about instructions that don't use the LOCK prefix.
1 reply 0 retweets 4 likes -
Replying to @cmuratori @Jonathan_Blow and
So we need to start understanding that "wait free" is the important thing, and "lock free" is more of a programming fetish thing that doesn't matter in the slightest as far as I've seen.
2 replies 0 retweets 16 likes -
This Tweet is unavailable.
Not sure what you mean. Writing to the data structure, "lock-free" or otherwise, will invalidate that cache line anyway. Using a mutex field in the cache line instead of a "lock-free" sequence of writes doesn't change that?
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.