Re: memory barriers (was: Yes, WaitLatch is vulnerable to weak-memory-ordering bugs)

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Thom Brown <thom(at)linux(dot)com>, Peter Geoghegan <peter(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: memory barriers (was: Yes, WaitLatch is vulnerable to weak-memory-ordering bugs)
Date: 2011-09-22 21:45:50
Message-ID: 1316727950.12660.2.camel@sussancws0025
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 2011-09-22 at 11:31 -0400, Robert Haas wrote:
> On Thu, Sep 22, 2011 at 11:25 AM, Thom Brown <thom(at)linux(dot)com> wrote:
> > s/visca-versa/vice-versa/
> > s/laods/loads/
>
> Fixed. v4 attached.
>

Can you please explain the "more subtly" part below?

+A common pattern where this actually does result in a bug is when
adding items
+onto a queue. The writer does this:
+
+ q->items[q->num_items] = new_item;
+ ++q->num_items;
+
+The reader does this:
+
+ num_items = q->num_items;
+ for (i = 0; i < num_items; ++i)
+ /* do something with q->items[i] */
+
+This code turns out to be unsafe, because the writer might increment
+q->num_items before it finishes storing the new item into the
appropriate slot.
+More subtly, the reader might prefetch the contents of the q->items
array
+before reading q->num_items.

How would the reader prefetch the contents of the items array, without
knowing how big it is?

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-09-22 23:12:41 Re: memory barriers (was: Yes, WaitLatch is vulnerable to weak-memory-ordering bugs)
Previous Message Pavel Stehule 2011-09-22 21:10:26 Re: patch: plpgsql - remove unnecessary ccache search when a array variable is updated