http://nohardlockrwlocker.codeplex.com/SourceControl/list/changesetsnohardlockrwlocker Source Code Rss Descriptionhttp://nohardlockrwlocker.codeplex.com/SourceControl/changeset/changes/19058Upgrade: New Version of LabDefaultTemplate.xaml. To upgrade your build definitions, please visit the following link: http://go.microsoft.com/fwlink/?LinkId=254563Project Collection Service AccountsMon, 01 Oct 2012 20:32:50 GMTSource code checked in, #19058 20121001083250Phttp://nohardlockrwlocker.codeplex.com/SourceControl/changeset/changes/19057Checked in by server upgradeProject Collection Service AccountsMon, 01 Oct 2012 20:31:07 GMTSource code checked in, #19057 20121001083107Phttp://nohardlockrwlocker.codeplex.com/SourceControl/changeset/changes/6738Broken. Sort of runs and better than what was there before. Still not fully atomic. Uses the idea of each thread having their own static fields.

Here I have the static fields as a Dictionary<int, int> where the key is the GetHashCode() of the ReadWriteLocker object, and the value is the number of times that thread has been incremented for read or write locking.

This is an alternative to making a thread-safe dictionary, which failed misserably before. At least this runs (but it locks up and the test fails).

In progress...

-TamusJRoyceTamusJRoyceMon, 02 May 2011 04:45:31 GMTSource code checked in, #6738 20110502044531Ahttp://nohardlockrwlocker.codeplex.com/SourceControl/changeset/changes/5454Fixed it so Thread.MemoryBarrier() is being used correctly for reading variables. Unsure if it really works. Don't have a multi-core/processor machine to test it on.

Otherwise, changing to Thread.VolatileRead()/VolatileWrite() will be needed.

Either way, speed is a huge issue now. May have to find a fundementally faster way of reference counting.

-TamusJRoyceTamusJRoyceSun, 23 Jan 2011 09:09:34 GMTSource code checked in, #5454 20110123090934Ahttp://nohardlockrwlocker.codeplex.com/SourceControl/changeset/changes/4969Broken, but enough clues as to why it isn't working so i can finish it up at a different computer.

This is using SharpDevelop. Don't bother downloading this checkin.TamusJRoyceWed, 15 Dec 2010 20:44:51 GMTSource code checked in, #4969 20101215084451Phttp://nohardlockrwlocker.codeplex.com/SourceControl/changeset/changes/4968Broken, but enough clues as to why it isn't working so i can finish it up at a different computer.

This is using SharpDevelop. Don't bother downloading this checkin.TamusJRoyceWed, 15 Dec 2010 20:44:51 GMTSource code checked in, #4968 20101215084451Phttp://nohardlockrwlocker.codeplex.com/SourceControl/changeset/changes/4953Was missing NoDeadLockingRWLocker.sln, making it impossible to open w/ visual studio. Still has Windows 7/i7 issue. I will try to improve on next build (be nice to own the hardware).TamusJRoyceWed, 15 Dec 2010 04:48:16 GMTSource code checked in, #4953 20101215044816Ahttp://nohardlockrwlocker.codeplex.com/SourceControl/changeset/changes/4885Bug seen on Windows 7 using a Intel i7 processor and selecting Yes to prevent deadlocks. I currently only own a single processor AMD 2600+ on Windows XP. So if anyone has the ability to test this with a multi-processor machine or hyperthreading and Windows Vista or 7, please comment in discussion about your results. I hope I've fixed the issue.

Renamed HardLock, such as Behavior.NoHardLock, to DeadLock, or Behavior.NoDeadLock.
I consider "hard locks" as infinite loops where 100% of the processor is being used and no progress is being made. I consider "dead locks" as the classic ABBA locking where all threads are sleeping and waiting on each other--using 0% of the processor and making no progress either.TamusJRoyceSat, 11 Dec 2010 18:56:51 GMTSource code checked in, #4885 20101211065651Phttp://nohardlockrwlocker.codeplex.com/SourceControl/changeset/changes/4884ignore this commit.TamusJRoyceSat, 11 Dec 2010 18:39:39 GMTSource code checked in, #4884 20101211063939Phttp://nohardlockrwlocker.codeplex.com/SourceControl/changeset/changes/4847New IdBasedReferenceCounter implemented. This means a lot of thread-safety has been removed from the locker. This results in less overhead and more parallelism with deadlock prevention!

Other things have been tuned up. Twice as fast as it use to be. But without deadlock prevention it is roughly 2-3x slower than ReaderWriterLockSlim. And with prevention, it is 5-6x slower.

I hope to improve it to be close to equal that of ReaderWriterLockSlim and at most 3x slower for prevention.

Tri-license also added to project.TamusJRoyceMon, 06 Dec 2010 21:08:42 GMTSource code checked in, #4847 20101206090842Phttp://nohardlockrwlocker.codeplex.com/SourceControl/changeset/changes/4142Removed the Wait/PulseAll in favor for ReaderWriterLockSlim's Sleep(1). It is now roughly 3 times slower than it, but many times quicker than before. Working on non-blocking thread tracking.

With the non-blocking thread tracking, I will be storing keys using radix buckets (keys are integers--ManagedThreadId) for parallelism, and sorted linked list within those buckets. This should be more memory efficient than using a dictionary/hash table, with identical speed.

Speed will be guaranteed by increasing the number of buckets if a certain threshold has been surpassed (similar to how a hash table expands when conflicts pass a threshold).TamusJRoyceSat, 06 Nov 2010 19:09:05 GMTSource code checked in, #4142 20101106070905Phttp://nohardlockrwlocker.codeplex.com/SourceControl/changeset/changes/3886In progress of getting performance better and demo working. It now does distribute the workload. Then pressing the button to start the race shows progress more evenly. Also, demo using 6 threads per horse rather than 2.

Spinlocks now do waiting if they spin too much. This pushes readwritelockers performance past the regular ReaderWriterLockSlim, though it is still about 2-8 times slower than ReaderWriterLockSlim. But that's involving the GUI, so it by far is not accurate.

As stable as previous checking.TamusJRoyceFri, 29 Oct 2010 13:24:13 GMTSource code checked in, #3886 20101029012413Phttp://nohardlockrwlocker.codeplex.com/SourceControl/changeset/changes/3794Reverted to before policy-per-lock is available. Comments are down too. Spinlocks implemented with read/upgrade/write spinlocks. Fixed other bugs.

Almost production ready (besides performance). The biggest hold back from allowing this to perform really good (performs ok, but still slow in my opinion) is not having non-blocking hashtables/dictionaries. That is the next thing I plan on getting to work. Then policy based locking with better comments.TamusJRoyceTue, 26 Oct 2010 03:07:02 GMTSource code checked in, #3794 20101026030702Ahttp://nohardlockrwlocker.codeplex.com/SourceControl/changeset/changes/3793Rolled back to before policy-per-lock and such. Commenting reduced. Spinlocks are implemented. ReadSpin, UpgradeSpin, and WriteSpin. Much more stable. Fixed other errors.

Plan is to next re-implement policy based locking, and implement non-blocking hash tables which is the major fallback to this locker (though the idea still holds merit). I'd say this is almost production ready for detecting deadlocks (minus performance).TamusJRoyceTue, 26 Oct 2010 02:25:57 GMTSource code checked in, #3793 20101026022557Ahttp://nohardlockrwlocker.codeplex.com/SourceControl/changeset/changes/3393This check-in runs slower than previous check-ins. In progress of implementing Policy Based Locking. It is easier to understand while having more comments.

Not a recommended download, but you are welcome to check it out.TamusJRoyceTue, 12 Oct 2010 09:15:30 GMTSource code checked in, #3393 20101012091530Ahttp://nohardlockrwlocker.codeplex.com/SourceControl/changeset/changes/3188Updating executables in debug directory.TamusJRoyceThu, 07 Oct 2010 06:58:19 GMTSource code checked in, #3188 20101007065819Ahttp://nohardlockrwlocker.codeplex.com/SourceControl/changeset/changes/3187PerformanceGraph project added. It's really a progress bar test between ReaderWriterLock, ReaderWriterLockSlim, and ReadWriteLocker.
Spinlocks implemented! There are no longer any SyncLocks/locks, except within the actual lock where waiting occurs.
Fixed an instance where SuperThread was being used when number of threads entered equal the number of threads locked, when both equal zero (so no threads are locked, and thus the SuperThread shouldn't be used).
TamusJRoyceThu, 07 Oct 2010 06:52:56 GMTSource code checked in, #3187 20101007065256Ahttp://nohardlockrwlocker.codeplex.com/SourceControl/changeset/changes/3035Performance improved. Below, by removing local locking, I mean I removed local deadlock prevention, which is redundant now that the regular read-write locker functionality works 100%. Before, nesting a read lock inside a write lock would deadlock, requiring a local super-thread work-around to not deadlock.

This check in updates the included executable.TamusJRoyceFri, 01 Oct 2010 14:50:10 GMTSource code checked in, #3035 20101001025010Phttp://nohardlockrwlocker.codeplex.com/SourceControl/changeset/changes/2992Found that upgrading from write lock to read lock on a single thread was using the SuperThread. Changed locking condition so read locks are upgradable to write locks and write locks to read locks without using the super-thread.
Also, removed unneeded local locking, as the condition for recursive local locking is working. It helped prevent deadlocking when the read-write locker logic was coded with the issue above.
Unit test updated to include simple test detecting this.

-TamusJRoyce
TamusJRoyceThu, 30 Sep 2010 04:14:20 GMTSource code checked in, #2992 20100930041420Ahttp://nohardlockrwlocker.codeplex.com/SourceControl/changeset/changes/2716ThreadSafeList Collection now implements ISimpleReadWriteLocker, exposing some of the ReadWriteLocker's functionality.

-TamusJRoyce
TamusJRoyceSat, 25 Sep 2010 07:47:24 GMTSource code checked in, #2716 20100925074724A