[chromium-dev] Re: Replacing BaseTransaction with a straight lock?
I see. Yeah, we've had to deal with the quit asap issues in other cases too. For example, the host resolver uses detached threads so that it can simply leak a thread that is stuck on a getaddrinfo call. (FF does the same thing.) -Darin On Wed, Sep 23, 2009 at 10:30 PM, Tim Steele t...@chromium.org wrote: Not IO. The only contention it comes up against would be trying to get a lock on data while another thread is applying changes that it already received from a server, but that work is not intensive; it could be done by the UI thread itself if it had to be, but it isn't since in the majority of cases it can just happen peacefully in the background. Except at shutdown, which is http://code.google.com/p/chromium/issues/detail?id=19757. On Wed, Sep 23, 2009 at 10:22 PM, Darin Fisher da...@chromium.org wrote: Chrome's UI thread blocks on IO? Please tell me I misunderstand :-) -Darin 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.comwrote: 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Replacing BaseTransaction with a straight lock?
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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Replacing BaseTransaction with a straight lock?
+Adding back chromium-dev -Munjal On Wed, Sep 23, 2009 at 5:22 PM, Munjal Doshi mun...@chromium.org wrote: I am not sure. But it doesn't seem crazy to use sync data as a database directly for certain data types. -Munjal On Wed, Sep 23, 2009 at 5:04 PM, Jonathan Huang ch...@google.com wrote: 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. 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? On Wed, Sep 23, 2009 at 5:02 PM, Munjal Doshi mun...@chromium.org wrote: One thing to think about is what would happen if we have multiple data types? If the lock is going to be scoped on the entire user directory versus specific data type umbrella then we would have more contention. Of course, this can happen in both simple lock or read/write lock world but depending on how other data types are used (if many concurrent reads are needed for example) read-write lock model might do better. In other words, even though read-write locks might not do much better than simple locks today, they might do better in future. But I am not necessarily opposed to using simple locks right now.. -Munjal On Wed, Sep 23, 2009 at 4:07 PM, brg b...@chromium.org wrote: Startup sync has little chance of collision as it is uncoordinated between machines, but model association occurs here and can cause a bit of a lag. Notifications incur a read immediately after being received from a write. When a user has more than one client open, these will collide. I think we can mitigate any problems with a small random wait which occurs between receiving a notification and doing the sync. Polling should have little chance of collision. 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Replacing BaseTransaction with a straight lock?
[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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Replacing BaseTransaction with a straight lock?
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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Replacing BaseTransaction with a straight lock?
Chrome's UI thread blocks on IO? Please tell me I misunderstand :-) -Darin 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 --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Replacing BaseTransaction with a straight lock?
Not IO. The only contention it comes up against would be trying to get a lock on data while another thread is applying changes that it already received from a server, but that work is not intensive; it could be done by the UI thread itself if it had to be, but it isn't since in the majority of cases it can just happen peacefully in the background. Except at shutdown, which is http://code.google.com/p/chromium/issues/detail?id=19757. On Wed, Sep 23, 2009 at 10:22 PM, Darin Fisher da...@chromium.org wrote: Chrome's UI thread blocks on IO? Please tell me I misunderstand :-) -Darin 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.comwrote: 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 -~--~~~~--~~--~--~---
