[Moving to chromium-dev]
Good question.
One case where we do any large amount of work with a ReadTransaction is the
LoadAssociations step of model association. This happens just once at
startup, and I don't expect there's another thread trying to do read-only
operations on the syncable::Directory at the same time.
Another case is TakeSnapshotForSaveChanges. But I don't see those two
interacting commonly.
Most of the stuff that happens on the UI thread already needs a
WriteTransaction, and there shouldn't typically be contention for many of
the operations because of how we dispatch (via ModelChangingSyncerCommand)
those operations onto the UI thread.
So really, I don't think we'd see an uptick in contention if we went with a
simpler lock.
- nick
On Wed, Sep 23, 2009 at 3:34 PM, Jonathan Huang <ch...@google.com> wrote:
>
> Hi,
>
> I talked to jim roskind about putting a read-write lock in chrome to
> replace our base transaction class and he was of the opinion that
> performance gains from rwlocks were often not very efficient. With
> that in mind, I think the way that our transactions work right now, we
> have a multitude of writers and not all that many readers. I'm
> thinking of just replacing our transactions with a straight lock.
>
> Is there UI that blocks right now on acquiring a read transaction
> that's likely to bump into another read transaction, or other
> considerations I haven't thought through?
>
> --
> As seen on TV
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
