I think in our current model, the outside entity that wants to sync
stuff with us needs to maintain a separate copy of their data. In the
future, if we sync other types, i'm not sure whether they want to do
that or not. If that's true, then we don't really need to provide a
read write lock.
However, if we're used as a general database, we do. Is there a
compelling reason to use us as a database? It seems like a bad idea.
On Wed, Sep 23, 2009 at 4:06 PM, Tim Steele <t...@chromium.org> wrote:
> 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
>>>
>>>
>>
>>
>> >>
>
>
--
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
-~----------~----~----~----~------~----~------~--~---
