W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: [IndexedDB] Avoiding reader/writer starvation

From: Jeremy Orlow <jorlow@chromium.org>
Date: Mon, 16 Aug 2010 11:06:02 +0100
Message-ID: <AANLkTikFY9fnhw-_1E2ahBj2Y=PXsVfPoDSDVUgG7Zsh@mail.gmail.com>
To: Pablo Castro <Pablo.Castro@microsoft.com>
Cc: public-webapps WG <public-webapps@w3.org>
On Fri, Aug 13, 2010 at 7:30 PM, Pablo Castro <Pablo.Castro@microsoft.com>wrote:

> In the context of transactions, readers using READ_ONLY and writers using
> READ_WRITE may block each other when starting transactions, at least for
> cases where the underlying implementation uses locking for isolation. Since
> we allow multiple readers and they can start while other readers were
> already running, it's possible that readers end up starving writers in a
> concurrent setting. It seems it would be a good idea to add some minimum
> guarantees to the spec that ensures some amount of fairness to concurrent
> activities against a given database.
> We could either include a loose recommendation or try to mandate a strict
> behavior. It seems the loose recommendation is more practical, the questions
> are a) is there a risk of incompatible behavior because of
> under-specification, and b) will we risk that some implementations will just
> ignore this aspect if it's specified too informally.
> The loose recommendation could just be a sentence in the transactions
> section:
> "UAs need to ensure a reasonable level of fairness across readers and
> writers to prevent starvation."
> If we wanted to be more specific, we could go with something like this
> (we'd probably spell it out as rules if we decide to put this strict version
> in the spec):
> "All readers can run concurrently, but once a writer tries to start a
> transaction we stop allowing new readers to start and queue up the writer
> and any subsequent reader/writer. Once the existing readers are drained the
> writer runs, and after that whatever is queued up next runs, which can be
> another writer or all the remaining readers (depending upon what came first,
> another writer or another reader; readers are released all simultaneously
> since they run concurrently)."
> Given that not all implementations will have to deal with this and that
> different implementations may want to have different strategies, it seems
> that just having the recommendation around starvation is the best option.

I agree that we should have some (non-normative?) recommendation to avoid
starvation in the spec and that anything more formal would be too

Received on Monday, 16 August 2010 10:06:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:10 UTC