On Mon, Nov 21, 2016 at 11:48 PM, Thomas Munro
wrote:
> Here's a version that works that way, though it allows you to call
> ConditionVariablePrepareToSleep *optionally* before you enter your
> loop, in case you expect to have to wait and would rather avoid the
>
At Tue, 22 Nov 2016 17:48:07 +1300, Thomas Munro
wrote in
On Tue, Nov 22, 2016 at 3:05 PM, Kyotaro HORIGUCHI
wrote:
> Hello,
>
> At Mon, 21 Nov 2016 15:57:47 -0500, Robert Haas wrote
> in
>> On Thu, Aug 11, 2016 at 5:47 PM,
Hello,
At Mon, 21 Nov 2016 15:57:47 -0500, Robert Haas wrote
in
> On Thu, Aug 11, 2016 at 5:47 PM, Robert Haas wrote:
> > So, in my
> > implementation, a condition variable wait
On Thu, Aug 11, 2016 at 5:47 PM, Robert Haas wrote:
> So, in my
> implementation, a condition variable wait loop looks like this:
>
> for (;;)
> {
> ConditionVariablePrepareToSleep(cv);
> if (condition for which we are waiting is satisfied)
> break;
>
On Mon, Nov 21, 2016 at 7:10 AM, Thomas Munro
wrote:
>> I wonder if we shouldn't try to create the invariant that when the CV
>> mutex is not help, the state of cvSleeping has to be true if we're in
>> the proclist and false if we're not. So
On Fri, Oct 28, 2016 at 9:38 AM, Robert Haas wrote:
> On Tue, Oct 4, 2016 at 3:12 PM, Thomas Munro
> wrote:
>> On Mon, Aug 15, 2016 at 5:58 PM, Thomas Munro
>> wrote:
>>> Please find attached a -v2 of your
On Tue, Oct 4, 2016 at 3:12 PM, Thomas Munro
wrote:
> On Mon, Aug 15, 2016 at 5:58 PM, Thomas Munro
> wrote:
>> Please find attached a -v2 of your patch which includes suggestions
>> 1-3 above.
>
> Here's a rebased patch.
On Tue, Oct 4, 2016 at 12:12 PM, Thomas Munro
wrote:
> Here's a rebased patch. ConditionVariableSleep now takes
> wait_event_info. Anyone using this in patches for core probably needs
> to add enumerators to the WaitEventXXX enums in pgstat.h to describe
> their
On Mon, Aug 15, 2016 at 5:58 PM, Thomas Munro
wrote:
> Please find attached a -v2 of your patch which includes suggestions
> 1-3 above.
Here's a rebased patch. ConditionVariableSleep now takes
wait_event_info. Anyone using this in patches for core probably needs
Maybe I can leave it up to you to determine if that applies in the context
of my parallel create index patch. You are the obvious candidate to review
that patch anyway, of course.
--
Peter Geoghegan
On Tue, Sep 13, 2016 at 10:55 PM, Peter Geoghegan wrote:
> On Thu, Aug 11, 2016 at 2:47 PM, Robert Haas wrote:
>> Another approach to the problem is to use a latch wait loop. That
>> almost works. Interrupts can be serviced, and you can recheck shared
>>
On Thu, Aug 11, 2016 at 2:47 PM, Robert Haas wrote:
> Another approach to the problem is to use a latch wait loop. That
> almost works. Interrupts can be serviced, and you can recheck shared
> memory to see whether the condition for proceeding is satisfied after
> each
On Tue, Sep 6, 2016 at 5:29 PM, Robert Haas wrote:
> On Mon, Sep 5, 2016 at 3:17 PM, Amit Kapila wrote:
>> On Mon, Aug 15, 2016 at 10:35 PM, Robert Haas wrote:
> Don't you need to set proc->cvSleeping = false in
On Mon, Sep 5, 2016 at 3:17 PM, Amit Kapila wrote:
> On Mon, Aug 15, 2016 at 10:35 PM, Robert Haas wrote:
Don't you need to set proc->cvSleeping = false in ConditionVariableSignal?
>>>
>>> I poked at this a bit... OK, a lot... and have some
On Mon, Aug 15, 2016 at 10:35 PM, Robert Haas wrote:
>>> Don't you need to set proc->cvSleeping = false in ConditionVariableSignal?
>>
>> I poked at this a bit... OK, a lot... and have some feedback:
>>
>> 1. As above, we need to clear cvSleeping before setting the latch.
On 2016-08-11 21:27:45 -0400, Robert Haas wrote:
> On Thu, Aug 11, 2016 at 6:37 PM, Peter Geoghegan wrote:
> > I notice that you acquire a spinlock within the implementation of
> > condition variables. Is it worth any effort to consolidate the number
> > of spinlock acquisitions?
On Mon, Aug 15, 2016 at 1:58 AM, Thomas Munro
wrote:
> On Sun, Aug 14, 2016 at 9:04 AM, Thomas Munro
> wrote:
>> On Fri, Aug 12, 2016 at 9:47 AM, Robert Haas wrote:
>>> [condition-variable-v1.patch]
>>
>> Don't
On Mon, Aug 15, 2016 at 5:58 PM, Thomas Munro
wrote:
> Also, I have attached a v2->v3 diff ...
Ugh. I meant a v1->v2 diff.
--
Thomas Munro
http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Sun, Aug 14, 2016 at 9:04 AM, Thomas Munro
wrote:
> On Fri, Aug 12, 2016 at 9:47 AM, Robert Haas wrote:
>> [condition-variable-v1.patch]
>
> Don't you need to set proc->cvSleeping = false in ConditionVariableSignal?
I poked at this a
On Fri, Aug 12, 2016 at 9:47 AM, Robert Haas wrote:
> [condition-variable-v1.patch]
Don't you need to set proc->cvSleeping = false in ConditionVariableSignal?
--
Thomas Munro
http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list
On Thu, Aug 11, 2016 at 8:44 PM, Thomas Munro
wrote:
> In contrast, this proposal leaves it up to client code to get that
> right, similarly to the way you need to do things in a certain order
> when waiting for state changes with latches. You could say that it's
>
On Thu, Aug 11, 2016 at 6:37 PM, Peter Geoghegan wrote:
> I notice that you acquire a spinlock within the implementation of
> condition variables. Is it worth any effort to consolidate the number
> of spinlock acquisitions? In other words, maybe the most common idioms
> should be
On Thu, Aug 11, 2016 at 6:12 PM, Tom Lane wrote:
>> But if we replace the io_in_progress locks with
>> condition variables, then that doesn't happen any more. Nobody is
>> "holding" the condition variable, so it doesn't get "released" when
>> the process doing I/O aborts.
On Fri, Aug 12, 2016 at 9:47 AM, Robert Haas wrote:
> https://en.wikipedia.org/wiki/Monitor_(synchronization)#Condition_variables_2
>
> Basically, a condition variable has three operations: you can wait for
> the condition variable; you can signal the condition variable to
On Thu, Aug 11, 2016 at 2:47 PM, Robert Haas wrote:
> Another approach to the problem is to use a latch wait loop. That
> almost works. Interrupts can be serviced, and you can recheck shared
> memory to see whether the condition for proceeding is satisfied after
> each
Robert Haas writes:
> I had what I think is a better idea, which is to introduce a notion of
> condition variables.
Interesting proposal.
> ... Using condition variables here seems to
> have a couple of advantages. First, it means that a backend waiting
> for buffer I/O
Hi,
Some of my EnterpriseDB colleagues and I have been working on various
parallel query projects, all of which have been previously disclosed
here:
https://wiki.postgresql.org/wiki/EnterpriseDB_database_server_roadmap
One issue we've encountered is that it's not very easy for one process
in a
28 matches
Mail list logo