tag:blogger.com,1999:blog-5246987755651065286.post8658522044106518902..comments2024-02-22T16:15:42.388-08:00Comments on cbloom rants: 05-26-09 - Automatic Multithreadingcbloomhttp://www.blogger.com/profile/10714564834899413045noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-5246987755651065286.post-86729134044768929532009-05-29T18:46:45.240-07:002009-05-29T18:46:45.240-07:00and of course to be clear on the context, this isn...and of course to be clear on the context, this isn't a general transaction thing, it's just needed when you're trying to replace locks and/or use locks as the fallback mechanism.cbloomhttps://www.blogger.com/profile/10714564834899413045noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-89963901493581593472009-05-29T18:45:46.404-07:002009-05-29T18:45:46.404-07:00So the transaction version is something like :
ch...So the transaction version is something like :<br /><br />checkpoint<br /><br />if ( lock.set )<br /> goto fallback<br /><br />lock.set = true<br /><br />.. do stuff ..<br /><br />lock.set = false<br /><br />commit<br />on failure goto fallback<br /><br />So the commit only goes through when I was the only person who got their hands on the lock during that time.<br /><br />Or something, I dunno, it's more complicated than that I'm sure.cbloomhttps://www.blogger.com/profile/10714564834899413045noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-4209791516074219572009-05-29T18:33:38.273-07:002009-05-29T18:33:38.273-07:00I think the key to that is that the light transact...I think the key to that is that the light transaction version still checks a bool in the lock. That does two things - if the bool is set it's locked and you don't do the transaction, but it also makes you dependent on the cache line of the lock, so if anyone else is changing the lock at the same time you fail the transaction.cbloomhttps://www.blogger.com/profile/10714564834899413045noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-29616432992785436462009-05-29T17:58:48.653-07:002009-05-29T17:58:48.653-07:00Does your example of lock avoidance actually work?...Does your example of lock avoidance actually work? It seems like the hardware transaction needs to be blocked by the lock; i.e. you don't want to fail a transaction, grab the lock, do part of the locked code, then pause and another thread comes along and runs the transaction code and completes it successfully.<br /><br />But I may not be understanding it correctly.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-85049792016228615162009-05-26T18:27:13.580-07:002009-05-26T18:27:13.580-07:00"Yeah I didn't see it; it's cool."
It's interestin..."Yeah I didn't see it; it's cool."<br />It's interesting how working on hardware, or even just thinking about how you would specify something if it was meant to be implemented as hardware, changes your perspective.<br /><br />It changes your focus from "what am I trying to accomplish" to "what am I actually doing", which is very liberating sometimes. I remember reading some time ago about how LLVM used to have signed and unsigned integers as distinct types, which they later switched that to just having integer types with distinct signed/unsigned add, sub and multiply instructions, which apparently solved several design problems for them.<br /><br />This kind of actually peeling high-level information away where it doesn't contribute anything anymore is just as tricky as getting the high-level info to where you need it.ryghttps://www.blogger.com/profile/03031635656201499907noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-83301479352492912552009-05-26T16:46:00.877-07:002009-05-26T16:46:00.877-07:00"The architecture folks realized pretty early on t..."The architecture folks realized pretty early on that transactions and speculation are basically the same thing."<br /><br />Yeah I didn't see it; it's cool.<br /><br />"I like the idea of a processor being able to dynamically choose to speculate or hyperthread, or just save power."<br /><br />Apparently Rock can be controlled from software to use both hardware hyperthreads to execute a single software thread. In that case one of the hyperthreads runs ahead and speculatively executes and prefetches stuff, while the other one hangs behind and retires what actually happened. <br /><br />It's cool to be able to control stuff like that from the OS so you have control over power use, whether you target fewer or more threads, etc.cbloomhttps://www.blogger.com/profile/10714564834899413045noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-66362858443603794672009-05-26T16:25:38.769-07:002009-05-26T16:25:38.769-07:00Pending thread annotations in GCC:
http://docs.go...Pending thread annotations in GCC:<br /><br />http://docs.google.com/Doc?id=ddqtfwhb_0c49t6zgr<br /><br />The architecture folks realized pretty early on that transactions and speculation are basically the same thing. I think it is also fairly obvious that you don't need to do a fully hardware implementation of transaction memory, just like you don't need to do a fully hardware implementation of virtual memory. <br /><br />I like the idea of a processor being able to dynamically choose to speculate or hyperthread, or just save power. It would be interesting to see what the "branch predictor" (or whatever would make that decision) would look like. I wonder if the additional complexity would be worthwhile. I suppose the problem is that to actually do speculation well you also need to go out-of-order, and things quickly get big and messy.won3dhttps://www.blogger.com/profile/09787472194187459747noreply@blogger.com