On Wed, 1 Jul 2020 11:49:01 +0200 Gustaf Neumann <neum...@wu.ac.at> wrote:
> There are already rwlocks in NaviServer since ages, used e.g. for epoch > management, ADP tags, permissions. The current version uses as well > rwlocks for nsv variables (most user visible part) and also for URLspace > and connchan handles. For URLspace, the write ratio is in the very low > per mille range (clear advantage for rwlocks), for connchan handles, it > is already better use rwlocks for channels with a single read operation, > and the benefit becomes larger with more channel interactions. This is > the current state - some parts still under evaluation. More details will > be in the summaries before the releases. I do not believe it is the optimal decision to put rwlocks (and thus favourize readers) at NSV, which is usage-pattern agnostic. You do not really know who/how will use shared arrays and forcing the reader/writer locks might be a drawback instead of a benefit in some cases. For usage-patterns that are predictable (one knows roughly what kind of access the data structures will encounter over time) one can then choose what is the best. Ideally, one would be able to select locking type on per-array basis, but that might be too cumbersome to program. So a compile-switch, which may not be the best, is the simplest option. Next would be a config option that would for example take a glob expression and assign locking type on nsv name-glob, putting desigated locking on all arrays that match given glob. > > Another interesting candidate is nscache, but the situation is more > complex: although - by construct - caches experience much more read than > write operations, the usage for rwlocks there would be rather complex, > since one has to know before the lock, whether an operation will be read > or write. But the lock guarding the main interface (nscache_eval) is > used for reading and writing, so it would require always a write lock. > So, due to my workload, i have no final opinion on the usefulness of > rwlocks in this context. Yes, the nscache_eval is problematc. Otherwise I'd say that nscache per-design would be a good candidate for rwlocks, unlike NSVs. One uses the cache mainly for things that are seldomly/expensively setup but often read. > > For the people not having an eye on the source code changes: One > important enabler/driver for these changes is the switch from the > "manual" rwlock implementation we had before towards using the rwlock > implementation from pthreads (we still use the "manual" rwlock > implementation for NaviServer variants compiled without pthreads, such > as the usual windows compilations). > > The newer implementations of pthreads in the Linux world benefit from > the work on futex variants (fast userspace mutex), which exist in new > Linux versions in many variants (wake-wait futex, priority inversion > futex, optimistic spinning futex formerly called throughout optimized > futex). As the results show, there is similar work going on e.g. on macOS. > Bottom line: I think it is more opportune to leave NSV locks as-is and add compile-option to use rwlocks if one's metric justify that. Or, add a more complex (and more versatile) config option using nsv name-globs. Personally... I am relaxed at this point since we do not use NSV's directly and extensively (we have our own private object-based interface). But for the sake of other (non-ACS users out there) I would trade stability/predictability over (possible) performance benefits. _______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
