If most of our uses on the UI thread are WriteTransactions today, then I
agree using a Lock alone can't make things any jankier, because if you need
to write you need the lock. I guess what I'm wondering is if we'll ever
discover we could improve UI responsiveness somehow by using a
ReadTransaction in places we haven't yet discovered. But I doubt it, since
the UI has it's own cache (BookmarkModel) of the data that should be the
only place it reads from.
Except the ModelAssociator seems to use ReadTransaction.. I'm not that
familiar with when that happens atm.
On Wed, Sep 23, 2009 at 4:05 PM, Nick Carter <n...@chromium.org> wrote:
> [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
-~----------~----~----~----~------~----~------~--~---
