AMD working on scaleable hardware-based atomic transactions...
|
Prev: Von Neumann and revisionists [Re: Future architectures [was Re: Intel details future Larrabee ...]]
Next: Von Neumann and revisionists [Re: Future architectures [was Re:Intel details future Larrabee ...]]
From: Dmitriy V'jukov on 1 Sep 2008 03:49 On 1 ÓÅÎÔ, 04:09, "Chris M. Thomasson" <n...(a)spam.invalid> wrote: > Here ya go: > > http://www.amd64.org/fileadmin/user_upload/pub/epham08-asf-eval.pdf Cool! It recalls Sun's HTM design, but AMD's design gives explicit control over what locations to lock and what not to lock. Interesting, when we will see it in AMD hardware? Also, if HTM will not be supported by Intel, usage will be very problematic. Dmitriy V'jukov
From: MitchAlsup on 1 Sep 2008 15:21 see this thread from midway down the first page: http://groups.google.com/group/comp.arch/browse_thread/thread/cedc2e76568ab0c5/934e3485d711d4a0?hl=en#934e3485d711d4a0
From: Chris M. Thomasson on 3 Sep 2008 19:43 [added comp.arch additional context for this topic can be found here: http://groups.google.com/group/comp.arch/browse_frm/thread/cedc2e76568ab0c5 ] "David Schwartz" <davids(a)webmaster.com> wrote in message news:92d923c4-1fdf-4287-a632-582a473b8891(a)i20g2000prf.googlegroups.com... >> Is this intended to be usable in ordinary application code? It >> appears, at least to me, to be basically unusable. Maybe I'm missing >> something. >> The problem is that once you pass the 'ACQUIRE' point, your code must >> run without pre-emption until you hit the 'COMMIT' point. If there's >> an interrupt, your code will be "aborted" (see section 3.3). The >> specification provides a way to detect an abort -- you jump back >> magically to your 'ACQUIRE' point and return an error. But I don't see >> how that helps you if the abort occurred after some, but not all, of >> your writes took place. >> The example code, such as Figure 1's supposed DCAS doesn't even try to >> handle this case. It will fail horribly if the code is interrupted or >> pre-empted in the 'critical section'. >> IMO, like so much synchronization code, the supposed 'simplicity' of >> this approach (and maybe even its alleged performance advantage) will >> evaporate when it has to handle all the nasty things that can happen >> in the real world. >> Maybe I'm missing something. If so, what? This post might shed some light: http://groups.google.com/group/comp.arch/msg/75109b08ea8a1ca4 Apparently, interrupts are deferred by the OS. I also believe that this deferment is adjustable by mutating a so-called watch-dog counter. "David Schwartz" <davids(a)webmaster.com> wrote in message news:faf93c3d-dd22-4035-a107-afea1ada2a62(a)k36g2000pri.googlegroups.com... On Sep 3, 7:27 am, David Schwartz <dav...(a)webmaster.com> wrote: > Well, I've read it more carefully, and it seems to sort of say that > they 'undo' all writes if there's an abort with a special buffer. > Their description seems kind of confusing to me. If they hold all > writes in a special buffer, how big is it? I believe the buffer is big enough to hold at least 7-8 words. If your transactions need more than that, then ASF is not the right tool for the job...
From: Chris M. Thomasson on 3 Sep 2008 19:45 "Dmitriy V'jukov" <dvyukov(a)gmail.com> wrote in message news:86c0c11f-785f-4456-9ee5-bfa5d4d8993a(a)56g2000hsm.googlegroups.com... On 1 ����, 04:09, "Chris M. Thomasson" <n...(a)spam.invalid> wrote: > > Here ya go: > > > > http://www.amd64.org/fileadmin/user_upload/pub/epham08-asf-eval.pdf > Cool! > It recalls Sun's HTM design, but AMD's design gives explicit control > over what locations to lock and what not to lock. > Interesting, when we will see it in AMD hardware? > Also, if HTM will not be supported by Intel, usage will be very > problematic. Good point. Humm... I guess that Intel will just have to acquire a license from AMD! ;^)
From: Zeljko Vrba on 4 Sep 2008 01:55
On 2008-09-04, David Schwartz <davids(a)webmaster.com> wrote: > > confident is correct. It takes serious expertise and reviews from > multiple people to make sure something doesn't slip by. With this, I > Could verification tools such as SPIN be of help there? |