Re: [HACKERS] condition variables

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 >

Re: [HACKERS] condition variables

At Tue, 22 Nov 2016 17:48:07 +1300, Thomas Munro wrote in

Re: [HACKERS] condition variables

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,

Re: [HACKERS] condition variables

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

Re: [HACKERS] condition variables

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; >

Re: [HACKERS] condition variables

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

Re: [HACKERS] condition variables

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

Re: [HACKERS] condition variables

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.

Re: [HACKERS] condition variables

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

Re: [HACKERS] condition variables

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

Re: [HACKERS] condition variables

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

Re: [HACKERS] condition variables

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 >>

Re: [HACKERS] condition variables

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

Re: [HACKERS] condition variables

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

Re: [HACKERS] condition variables

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

Re: [HACKERS] condition variables

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.

Re: [HACKERS] condition variables

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?

Re: [HACKERS] condition variables

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

Re: [HACKERS] condition variables

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

Re: [HACKERS] condition variables

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

Re: [HACKERS] condition variables

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

Re: [HACKERS] condition variables

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 >

Re: [HACKERS] condition variables

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

Re: [HACKERS] condition variables

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.

Re: [HACKERS] condition variables

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

Re: [HACKERS] condition variables

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

Re: [HACKERS] condition variables

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