Description
Note: issue #112 "HTHREADS thread-priorities implementation appears BORKED" appears to be closely related to this one.
Significant enhancements to Hercules's lock handling has been done over the years (mostly for integrity/error-checking purposes), resulting in a likely inefficient design and implementation (based on looking at the code), thereby slowing down all of Hercules given how much it (or any multi-threaded program, really!) relies on locks for controlled access to shared resources.
A detailed review, redesign and potential complete rewrite appears to very likely be in order.
One thing that might possibly be done right away is to have separate debug and non-debug versions of all locking functions to eliminate the overhead that exists in the current design, which currently tries hard to catch locking errors (which as we all know are otherwise notoriously difficult to catch).
But the most important change that could probably be made is to implement RW locking support in Windows and then leverage RW locking in all of Hercules.
POSIX pthreads has long supported RW locks (pthread_rwlock... set of functions) but Windows only introduced "Slim Reader/Writer (SRW) Locks" starting with Windows Vista, and due to Windows XP being, at the time, our minimum supported platform, our hthreads implementation for Windows failed to support it (and we never bothered to try replacing our existing mutex locks with R/W locks anywhere within Hercules either as a result).
Now that the minimum supported platform for SoftDevLabs Hyperion has been changed to Windows Vista or greater however, concerned effort should be undertaken to provide native Windows R/W locking support via Windows's "Slim Reader/Writer (SRW) Locks" functions.
Bottom line: Hercules's HTHREADS implementation needs a lot of attention!