On 23.08.2006, at 16:17, Vlad Seryakov wrote:
Looking thru the code i see that mostly only fastpath and log uses NsConfig reads in real time, all others are copy values into local structures. funny, but these who uses config are performance critical and will introduce lock contention because thet are figthing for the same config values. Another raw/uncooked idea: is it possible to keep changed values separately, no lock default config as is now and whoever changed value just keep it in the lock-guarded hash. If i care about locking and changed value i will check new hash for new value, others who does not may still use read-only config list.
I do not know how this could work. If thread A changes ns/some/thing and thread B is constantly looking up the ns/some/thing then the B must always lock to get the value, as A may be fiddling with it at the same time. Thread B can of course copy the value in its private (tsd) copy on the first fetch but then again, HOW is he going to find out that the thing was changed by the A in the meantime? I do not believe you can avoid locking if you want to have consistent behaviour. Also, the changes done by thread A would be pretty meaningless if only A is able to see them... I do not believe this is worth examining. As said, locking cannot be avoided. It is just the question of: can we tolerate it or not? I can. Therefore for me it is irelevant. But I do not if you can. Therefore I'm looking to see if we can do this as runtime or compile-time option. Also, because the locking is needed, we have to see how we can minimize it, also minimizing time spent in the locked sections of the code (by speeding up certain operations for example). Cheers Zoran
