On Thu, Sep 22, 2011 at 11:31 AM, Robert Haas wrote:
> On Thu, Sep 22, 2011 at 11:25 AM, Thom Brown wrote:
>> s/visca-versa/vice-versa/
>> s/laods/loads/
>
> Fixed. v4 attached.
Since it seems like people are fairly happy with this now, I've gone
ahead and committed this version. I suspect the
On Thu, Sep 22, 2011 at 7:46 PM, Jeff Davis wrote:
> On Thu, 2011-09-22 at 19:12 -0400, Robert Haas wrote:
>> But since you asked... as I
>> understand it, unless you're running on Alpha, you actually don't need
>> a barrier here at all, because all currently-used CPUs other than
>> alpha "respect
On Thu, 2011-09-22 at 19:12 -0400, Robert Haas wrote:
> But since you asked... as I
> understand it, unless you're running on Alpha, you actually don't need
> a barrier here at all, because all currently-used CPUs other than
> alpha "respect data dependencies", which means that if q->num_items is
>
On Thu, Sep 22, 2011 at 5:45 PM, Jeff Davis wrote:
> +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 r
On Thu, 2011-09-22 at 11:31 -0400, Robert Haas wrote:
> On Thu, Sep 22, 2011 at 11:25 AM, Thom Brown 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 bu
Robert Haas wrote:
> I've also added a lengthy README file to the patch that attempts
> to explain how barriers should be used in PostgreSQL coding. It's
> certainly not a comprehensive treatment of the topic, but
> hopefully it's enough to get people oriented. I've attempted to
> tailor it a
Excerpts from Robert Haas's message of jue sep 22 12:18:47 -0300 2011:
> I've also added a lengthy README file to the patch that attempts to
> explain how barriers should be used in PostgreSQL coding.
Very enlightening, thanks. Note a typo "laods".
--
Álvaro Herrera
The PostgreSQL Company -
On Thu, Sep 22, 2011 at 11:25 AM, Thom Brown wrote:
> s/visca-versa/vice-versa/
> s/laods/loads/
Fixed. v4 attached.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
barrier-v4.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (
On 22 September 2011 16:18, Robert Haas wrote:
> On Thu, Sep 22, 2011 at 10:53 AM, Peter Geoghegan
> wrote:
>> As I've already pointed out, the comment "Won't work on Visual Studio
>> 2003" is not accurate:
>>
>> http://msdn.microsoft.com/en-us/library/f20w0x5e(v=vs.71).aspx
>>
>> Besides, if it
On Thu, Sep 22, 2011 at 10:53 AM, Peter Geoghegan wrote:
> As I've already pointed out, the comment "Won't work on Visual Studio
> 2003" is not accurate:
>
> http://msdn.microsoft.com/en-us/library/f20w0x5e(v=vs.71).aspx
>
> Besides, if it's not supported, why bother mentioning it?
I mentioned it
On 14 September 2011 21:29, Robert Haas wrote:
> On Mon, Aug 8, 2011 at 7:47 AM, Robert Haas wrote:
>> I've been thinking about this too and actually went so far as to do
>> some research and put together something that I hope covers most of
>> the interesting cases. The attached patch is pretty
On Wed, Sep 21, 2011 at 5:07 PM, Kevin Grittner
wrote:
> That's the sort of thing where it would be helpful to provide one or
> two URLs for cogent explanations of this. Even if it takes repeated
> readings and meditations on the explanations for it to sink in, this
> is worth it. (For SSI I had
Robert Haas wrote:
> there are three questions that you might want to answer here:
>
> 1. I have a new architecture and I want barrier.h to support it.
>What do I need to do?
> 2. What is the behavior of the various constructs provided by
>barrier.h?
> 3. Why would I want that behavior
On Wed, Sep 21, 2011 at 3:39 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>> On Wed, Sep 21, 2011 at 2:48 PM, Kevin Grittner
>> wrote:
>>> Robert Haas wrote:
But even a full explanation of that case seems like almost too
much for the comment of a header file, and there are certainly
On Wed, Sep 21, 2011 at 4:19 PM, Gurjeet Singh wrote:
> On Wed, Sep 14, 2011 at 4:29 PM, Robert Haas wrote:
>>
>> On Mon, Aug 8, 2011 at 7:47 AM, Robert Haas wrote:
>> > I've been thinking about this too and actually went so far as to do
>> > some research and put together something that I hope
On Wed, Sep 14, 2011 at 4:29 PM, Robert Haas wrote:
> On Mon, Aug 8, 2011 at 7:47 AM, Robert Haas wrote:
> > I've been thinking about this too and actually went so far as to do
> > some research and put together something that I hope covers most of
> > the interesting cases. The attached patch
Robert Haas wrote:
> On Wed, Sep 21, 2011 at 2:48 PM, Kevin Grittner
> wrote:
>> Robert Haas wrote:
>>> But even a full explanation of that case seems like almost too
>>> much for the comment of a header file, and there are certainly
>>> far more complex cases. I think anyone who is using these
On Wed, Sep 21, 2011 at 2:48 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>> But even a full explanation of that case seems like almost too
>> much for the comment of a header file, and there are certainly far
>> more complex cases. I think anyone who is using these primitives
>> is going to h
Robert Haas wrote:
> But even a full explanation of that case seems like almost too
> much for the comment of a header file, and there are certainly far
> more complex cases. I think anyone who is using these primitives
> is going to have to do some independent reading...
Maybe a URL or two i
On Thu, Sep 15, 2011 at 11:57 AM, Heikki Linnakangas
wrote:
> s/atomic/barrier/
Oops.
>> +/*
>> + * A compiler barrier need not (and preferably should not) emit any
>> actual
>> + * machine code, but must act as an optimization fence: the compiler must
>> not
>> + * reorder loads or stores to ma
On 14.09.2011 23:29, Robert Haas wrote:
On Mon, Aug 8, 2011 at 7:47 AM, Robert Haas wrote:
I've been thinking about this too and actually went so far as to do
some research and put together something that I hope covers most of
the interesting cases. The attached patch is pretty much entirely
u
On Mon, Aug 8, 2011 at 7:47 AM, Robert Haas wrote:
> I've been thinking about this too and actually went so far as to do
> some research and put together something that I hope covers most of
> the interesting cases. The attached patch is pretty much entirely
> untested, but reflects my present be
22 matches
Mail list logo
