aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/OpenSim/Framework/IGenericConfig.cs
diff options
context:
space:
mode:
authorJustin Clark-Casey (justincc)2013-07-16 23:00:07 +0100
committerJustin Clark-Casey (justincc)2013-07-16 23:00:07 +0100
commit50b8ab60f2d4d8a2cc7024012fc1333be7635276 (patch)
tree898d5d485db4bc1ebd2a48cead0ae6008628b39b /OpenSim/Framework/IGenericConfig.cs
parentRevert "MSDN documentation is unclear about whether exiting a lock() block wi... (diff)
downloadopensim-SC-50b8ab60f2d4d8a2cc7024012fc1333be7635276.zip
opensim-SC-50b8ab60f2d4d8a2cc7024012fc1333be7635276.tar.gz
opensim-SC-50b8ab60f2d4d8a2cc7024012fc1333be7635276.tar.bz2
opensim-SC-50b8ab60f2d4d8a2cc7024012fc1333be7635276.tar.xz
Revert "Revert "MSDN documentation is unclear about whether exiting a lock() block will trigger a Monitor.Wait() to exit, so avoid some locks that don't actually affect the state of the internal queues in the BlockingQueue class.""
This reverts commit 21a09ad3ad42b24bce4fc04c6bcd6f7d9a80af08. After more analysis and discussion, it is apparant that the Count(), Contains() and GetQueueArray() cannot be made thread-safe anyway without external locking And this change appears to have a positive impact on performance. I still believe that Monitor.Exit() will not release any thread for Monitor.Wait(), as per http://msdn.microsoft.com/en-gb/library/vstudio/system.threading.monitor.exit%28v=vs.100%29.aspx so this should in theory make no difference, though mono implementation issues could possibly be coming into play.
Diffstat (limited to 'OpenSim/Framework/IGenericConfig.cs')
0 files changed, 0 insertions, 0 deletions