Derek (mantis #28830)
o ability for a thread to acquire a readlock when it already holds a
write lock, or vice versa
o detect when thread1 releases a lock while it hadn't acquired one
o correct result of beginwrite (return true only when another thread
held/acquired a write lock before the current thread got it)
o extra compared to Derek's patch: replaced some additional
(mostly pre-existing) interlocked*() hacks with proper memory
barriers, made formatting consistent, fixed compilation on platforms
where tthreadid is not an integer type, improved tthreadid hashing
function for 64 bit platforms, fixed some comments
git-svn-id: trunk@34678 -
using memory barriers, rather than half-heartedly using atomic
operations. Fixes random failures in trwsync on POWER7 processors
(and probably other weakly ordered architectures)
git-svn-id: trunk@27723 -
atomic operations so that in case it's created while multiple threads are
already running, all threads are guaranteed to see this initialisation
* some minor changes to the comments of TMREWS
git-svn-id: trunk@15074 -
so the TMultiReadExclusiveWriteSynchronizer routines can be safely
executed even with the default thread manager -> removed ismultithread
checks, so that it keeps working even if ismultithread is set to true
between acquiring and freeing a lock (mantis #15619)
git-svn-id: trunk@14830 -
TMultiReadExclusiveWriteSynchronizer, to ensure that out-of-order
execution cannot already perform some reads inside the critical section
before the lock has been acquired
- removed now unnecessary read barrier before releasing a read lock
git-svn-id: trunk@14820 -
critical section, so that it can be entered recursively just like
the one from TSimpleRWSync + test
- reverted r14593, since the reason for using TRWSync instead of
TMultiReadExclusiveWriteSynchronizer was because the former
supported recursive write locks
git-svn-id: trunk@14594 -
(to remove warnings)
* don't give a thread error for basicevent and threadevent routines if
isMultiThreaded is false, except for the waiting routines (the new
TMultiReadExclusiveWriteSynchronizer creates/sets such events in the
constructor, which caused thread manager errors in case cthreads was
not used under unix)
* don't perform any actual locking in TMultiReadExclusiveWriteSynchronizer
routines if isMultiThreaded is false (in order to avoid the errors
described above)
+ added generic RTLeventResetEvent stub
git-svn-id: trunk@14592 -
