Re:Ruby’s GIL and transactional memory
by twoodfin on Wednesday January 01, 2014 @07:08PM
(#6997426)
I haven't read the linked paper yet, but if transactional memory can be used in a feedback loop with the developer to identify sources of resource contention (where, for example, more intricate locking could usefully replace both TM and the GIL) that sounds like a real win.
[ Parent
| on HN ]
Re:Ruby’s GIL and transactional memory
by memracom on Wednesday January 01, 2014 @10:28PM
(#6998036)
To me locking means waiting which means greatly reduced performance. That is the whole reason why event-based systems like NGINX and node.js are so popular.
Look at the first slide from this talk by Professor Michael Stonebraker to see why more locking is not such a good idea. http://blog.jooq.org/2013/08/24/mit-prof-michael-stonebraker...
Just because we can do it doesn't mean that we should do it.
> To me locking means waiting which means greatly reduced performance. That is the whole reason why event-based systems like NGINX and node.js are so popular.
I think you've got it slightly wrong. What do you think happens when one request is being worked on in effectively one green-thread-equivalent in node.js? Everything else is blocked until the current operation yields. That's an equivalent of a GIL, yet it doesn't "reduce performance". If you switched to multithreading + locking (making it run in a M+N scheduling model), you'd gain performance, not lost it.