Re: [HACKERS] condition variables

2016-11-22 Thread Robert Haas
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

2016-11-22 Thread Kyotaro HORIGUCHI
At Tue, 22 Nov 2016 17:48:07 +1300, Thomas Munro wrote in

Re: [HACKERS] condition variables

2016-11-21 Thread Thomas Munro
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

2016-11-21 Thread Kyotaro HORIGUCHI
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

2016-11-21 Thread Robert Haas
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

2016-11-21 Thread Robert Haas
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

2016-11-21 Thread Thomas Munro
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

2016-10-27 Thread Robert Haas
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

2016-10-23 Thread Peter Geoghegan
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

2016-10-04 Thread Thomas Munro
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

2016-09-15 Thread Peter Geoghegan
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

2016-09-14 Thread Robert Haas
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

2016-09-13 Thread Peter Geoghegan
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

2016-09-06 Thread Amit Kapila
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

2016-09-06 Thread Robert Haas
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

2016-09-05 Thread Amit Kapila
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

2016-08-16 Thread Andres Freund
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

2016-08-15 Thread Robert Haas
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

2016-08-15 Thread Thomas Munro
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

2016-08-14 Thread Thomas Munro
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

2016-08-13 Thread Thomas Munro
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

2016-08-11 Thread Robert Haas
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

2016-08-11 Thread Robert Haas
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

2016-08-11 Thread Robert Haas
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

2016-08-11 Thread Thomas Munro
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

2016-08-11 Thread Peter Geoghegan
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

2016-08-11 Thread Tom Lane
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

[HACKERS] condition variables

2016-08-11 Thread Robert Haas
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