Re: pserialize(9) vs. TAILQ

[Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>]

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.

Dennis Ferguson