As someone who did that same perf work nah, you really want a good solid implementation if you want to run a reasonable amount of tasks without having workers stall the main thread. You never want the main thread to get blocked and miss a frame because it tried to queue a task.
-
-
Replying to @_tomcc @Jonathan_Blow
Sounds like perhaps the design is not thinking about it well for multithreaded (and hiding that behind lockless stuff); for example just cache the new entries on thread local and then do your lock & bulk copy at a well-controlled time.
1 reply 0 retweets 0 likes -
Replying to @kalin_t @Jonathan_Blow
I don't really see how avoiding locking is "not thinking about it well"... making an entire class of bugs impossible is definitely thinking about it well. Use the right tool for the job! A ton of duct tape around mutexes probably ain't it.
0 replies 0 retweets 1 like -
This Tweet is unavailable.
-
Replying to @Jonathan_Blow @kalin_t
That’s cool but calling names isn’t a point...
0 replies 0 retweets 2 likes -
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
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.
-
-
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.
- Show replies
New conversation -
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.