From: Zoran V. <zv...@ar...> - 2006-08-31 14:48:14
|
On 22.08.2006, at 22:13, Stephen Deasey wrote: > > I don't see how you will handle the locking... :-( If you go and get the: https://sourceforge.net/tracker/? func=detail&atid=719009&aid=1549952&group_id=130646 you can inspect the code ans see how I'm doing the locking. Essentially (in a nutshell) every thread has its own private copy of all config parameters it requested so far. There is also a shared configuration, holding ALL known config parameters. Under normal circumstances, a reader will go to the shared config for a parameter only once: first time it fetches the param. All other accesses to the same param are done in the local (per-thread) cache. The cache is locked in order to synchtonize with the writer thread. A writer thread will update the shared config and then walk private configs of all theads (which registered themselves for a given section - see above) and update them one by one, locking each as it goes. Since I expect writers to be *far* less active, the reader will almost always succeed in locking the private cache. Hence, almost no locking contention! A bad scenario can happen if you have numerous threads reading the same parameter at the same time. Then you will get contention on the shared config mutex. But this is normally not going to happen in real life, and if it happens it will be a very short interval as after that all will be cached per-thread privately. I believe this is pretty good. It uses some more memory but avoids locking contention at maximum. What do you think? Cheers Zoran |