Re: optimization possibilities...

"Timothy Baldwin" <spamtrap@[EMAIL PROTECTED]
> wrote in message 
news:I6udnYSpJJHXo5PVRVnyuQA@[EMAIL PROTECTED]
> In message <-NedndNK0e2y2pfVnZ2dnUVZ_o3inZ2d@[EMAIL PROTECTED]
>, Chris
Thomasson
> <spamtrap@[EMAIL PROTECTED]
> wrote:
>
>> x86 is TSO such that stores have implied preceding (#LoadStore |
>> #StoreStore), and loads have a implied trailing (#LoadStore |
#LoadLoad).
>> The only explicit memory barrier you need is (#StoreLoad | #StoreStore)

>> to
>> prevent load-after-store reordering; here is the do***entation:
>>
>> http://www.intel.com/products/processor/manuals/318147.pdf
>
> I was working to some earlier Intel docs.

That do***ent covers all Intel processors under IA-32/64 model.




> I have done some searching and
> found re****ts that explicit memory barriers are required on Pentium Pro 
> and
> Winchip processors, and some 486 and Pentium systems. There is sup****t
for
> such processors in Linux.

Are you referring to the plan9 problem?

http://groups.google.com/group/comp.programming.threads/msg/673a99c1328867cd

AFAICT, that's not referring to releasing a lock. I would be interested to

see some do***entation that explicitly says that you need a #StoreLoad 
barrier to release a lock on IA-32. That would totally contradict Intel's 
do***entation. I could easily add them in, but #StoreLoad on acquire _and_

release would tank performance for uncontended lock access.