On Thursday 15 September 2005 09:52, Andreas Fredriksson wrote: [SNIP] > The point I was trying to make is that if there are no locks involved at > all, and only a single write of a field (as appears to be the case > here), a reader might theoretically never see the written value, ever, > as the view of memory only passes when the writer threads enters a > monitor. > > So in this context, assuming there were no other monitors entered after > the change to the action field, another thread might still see the > default value, and take the wrong action. By locking around _something_, > (the own object in this case), we at least give other threads a fair > chance to see the value we're written by taking any required flush > actions to satisfy the memory view model. > > I agree that if read/write ordering is an issue in the design, locking > must be done on a much higher level which covers the event sequencing, > but I assume this is already accounted for in the class we're talking > about. > > Regards, > Andreas
Silly question... It looks like you have two issues. Deadlock contention and Transaction level isolation. I mean, if you have a single write, by default its atomic and you don't need locking. To your point above, if another thread is reading the database, then the isolation level of the transaction will take care of the issue. (Dirty Reads for example. ;-) [Its what you're describing.] If you have multiple writes that comprise an atomic action, then you need to have locking. (Which is what we are all agreeing with.) If you have n writes and you don't know if n=1 or n>1 then you could argue that a simple solution would be to lock for all transactions, thus keeping the code simple, at a performance hit. (Locking has a cost, but we don't know how much of a performance hit we will incur.) Balance that against the cost to check and see the value of n, if known... Does that make sense, or am I still suffering from the DTs? -- Michael Segel Principal MSCC (312) 952-8175
