Neil Conway wrote:
> On Thu, 2004-12-02 at 09:59 -0500, Bruce Momjian wrote:
> > OK, either you have to own the issue or I have to add something to the
> > TODO list.
>
> Can you add it to the TODO list and assign it to me?
>
Done:
* Fix priority ordering of read and write light-weight
On Thu, 2004-12-02 at 09:59 -0500, Bruce Momjian wrote:
> OK, either you have to own the issue or I have to add something to the
> TODO list.
Can you add it to the TODO list and assign it to me?
-Neil
---(end of broadcast)---
TIP 3: if posting/re
Neil Conway <[EMAIL PROTECTED]> wrote on 02.12.2004, 05:55:43:
> On Wed, 2004-12-01 at 21:51 -0500, Bruce Momjian wrote:
> > Neil, where are we on this? Should we add comments? Add a TODO? A patch?
>
> I'm not sure what the right resolution is. As I said, I don't think it's
> wise to apply a p
OK, either you have to own the issue or I have to add something to the
TODO list.
---
Neil Conway wrote:
> On Wed, 2004-12-01 at 21:51 -0500, Bruce Momjian wrote:
> > Neil, where are we on this? Should we add comments? Add
On Wed, 2004-12-01 at 21:51 -0500, Bruce Momjian wrote:
> Neil, where are we on this? Should we add comments? Add a TODO? A patch?
I'm not sure what the right resolution is. As I said, I don't think it's
wise to apply a patch that could have a significant impact on
performance without (a) testi
Neil, where are we on this? Should we add comments? Add a TODO? A patch?
---
Neil Conway wrote:
> On Wed, 2004-11-24 at 23:30 -0500, Tom Lane wrote:
> > It is not a 100% solution because it does not
> > cover the case whe
On Thu, 2004-11-25 at 11:28, Neil Conway wrote:
> Simon Riggs wrote:
> > I'd been thinking about lock release order also, thinking that this
> > could be related to the CS storms observed earlier and the apparent
> > lock-step behaviour commented upon previously.
>
> As much as I would love to bel
Simon Riggs wrote:
I'd been thinking about lock release order also, thinking that this
could be related to the CS storms observed earlier and the apparent
lock-step behaviour commented upon previously.
As much as I would love to believe this (because it would mean we could
probably solve the probl
On Wed, 2004-11-24 at 12:52, Neil Conway wrote:
> Bruce Momjian wrote:
> > I thought the new readers will sit after the writer in the FIFO queue so
> > the writer will not starve.
>
> AFAICS, that is not the case. See lwlock.c, circa line 264: in LW_SHARED
> mode, we check if "exclusive" is zero;
On Wed, 2004-11-24 at 23:30 -0500, Tom Lane wrote:
> It is not a 100% solution because it does not
> cover the case where a waiting exclusive locker is released, then a new
> shared locker arrives at the lock before the exclusive locker is given
> any cycles to acquire the lock. However I don't se
I wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
>> AFAICS, that is not the case. See lwlock.c, circa line 264: in LW_SHARED
>> mode, we check if "exclusive" is zero; if so, we acquire the lock
>> (increment the shared lock count and do not block). And "exclusive" is
>> set non-zero only when
Neil Conway <[EMAIL PROTECTED]> writes:
> (Speaking of which, the "exclusive" field is declared as a "char"; I
> wonder if it wouldn't be more clear to declare it as "bool", and treat
> it as a boolean field.
I coded it that way because I was thinking of it as a count (0 or 1),
for symmetry with
Neil Conway <[EMAIL PROTECTED]> writes:
> AFAICS, that is not the case. See lwlock.c, circa line 264: in LW_SHARED
> mode, we check if "exclusive" is zero; if so, we acquire the lock
> (increment the shared lock count and do not block). And "exclusive" is
> set non-zero only when we _acquire_ a
Neil Conway <[EMAIL PROTECTED]> writes:
> LWLockRelease() currently does something like (simplifying a lot):
> ...
> This has the nice property that locks are granted in FIFO order. Is it
> essential that we maintain that property?
Not really, although avoiding indefinite starvation is important.
Bruce Momjian wrote:
I thought the new readers will sit after the writer in the FIFO queue so
the writer will not starve.
AFAICS, that is not the case. See lwlock.c, circa line 264: in LW_SHARED
mode, we check if "exclusive" is zero; if so, we acquire the lock
(increment the shared lock count and
Neil Conway wrote:
> Bruce Momjian wrote:
> > My guess is the existing behavior was designed to allow waking of
> > multiple waiters _sometimes_ without starving of exclusive waiters.
>
> Well, I think the current algorithm *does* allow starvation, at least in
> some situations. Consider a worklo
Bruce Momjian wrote:
My guess is the existing behavior was designed to allow waking of
multiple waiters _sometimes_ without starving of exclusive waiters.
Well, I think the current algorithm *does* allow starvation, at least in
some situations. Consider a workload in which a new shared reader
arr
Neil Conway wrote:
> LWLockRelease() currently does something like (simplifying a lot):
>
> acquire lwlock spinlock
> decrement lock count
> if lock is free
> if first waiter in queue is waiting for exclusive lock,
> awaken him; else, walk through the queue and awaken
>
18 matches
Mail list logo
