Re: [PATCH] PPC lll_mutex_unlock_force write barrier
"Alexander Terekhov" <[email protected]>
| Newsgroups | gmane.comp.lib.phil |
|---|---|
| Organization | http://freemail.web.de/ |
| Message-ID | <[email protected]> |
[email protected] schrieb am 26.08.03 22:01:23: > > For Power4 and future processors with long store queues and out of order > execution, lll_mutex_unlock_force needs a write barrier between the store and > the futex syscall. Sort of. First off, unless I'm just missing and/or misunderstanding something, you've put it in the wrong place. Also, a write barrier isn't enough here. mutex.unlock also needs a read barrier. And both should be 'sink' barriers in this case (mutex.lock needs 'hoist' ones). Well, a hypothetical rdunlock operation (on a read-write lock) would need a 'sink-load' barrier only (no need whatsoever for constraining reordering of stores)... if only compiler folks would 'catch up' on this... regards, alexander. P.S. AFAICS, Intel's OP.RELEASE msync stuff can be viewed as an atomic operation with combined sink-load and sink-store barriers. Well, <http://google.com/groups?selm=3EE0CA46.593F938B%40web.de>. __________________________________________________________________________ Die sicherste Form der Kommunikation: E-Mails verschluesseln, Spam-Filter, Adressverifizierung, digitale Unterschrift: http://freemail.web.de