[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pserialize(9) vs. TAILQ
On 22 Nov, 2014, at 11:56 , Masao Uebayashi <uebayasi%gmail.com@localhost> wrote:
> On Sat, Nov 22, 2014 at 11:49 AM, Masao Uebayashi <uebayasi%gmail.com@localhost> wrote:
>> It is users' choice whether using fast-changing values as a key or
>> not, but if you decide to change values visible by pserialize(9)
>> readers, you'll end up with ensuring memory order. It is your choice,
>> but beyond pserialize(9)'s responsibility.
> Correction: changing values can be read by volatile. No memory
> barrier is needed if there's no memory ordering constraint.
Using volatile is very frequently a bug. You have two closely
related problems to deal with on a multiprocessor, that the
compiler may reorder or eliminate memory accesses and that the
processor cache hardware may reorder or eliminate memory accesses.
If you attempt to fix a problem with volatile (and you seem to
realize there is a problem if you are using volatile to fix it)
you may fix the compiler problem but do nothing to fix the cache
hardware problem. A barrier fixes both at the same time.
Main Index |
Thread Index |