A few questions...

Sep 26, 2010 at 11:59 AM

I looked over your example code, on the main page, and I got a few questions.

First, can you say something on why deadlocks will not occur?

Specific scenarion: What if two threads both acquire the read-lock, and then both attempts to acquire the write-lock? I would assume that the first thread to attempt this would block, because the other thread has a read-lock. And then the other thread would attempt it, also blocking. What happens in this scenario with this lock class?

The thread-safe list. Is it 1-based? If not, how can "List.RemoveAt(List.Count)" actually work? Also, the while-loop that is shown as "this is thread-safe, but it isn't very clear why", what if the list is cleared after you read Count, and thus enters the block?

Coordinator
Sep 29, 2010 at 2:40 AM

The title "Problems Solved" explains some of this, but I understand it isn't well explained.  Since both threads will be locked up, and the number of threads that start locking will equal the number of threads that are locked, one will be assigned as the super thread, allowing only it to run until super thread completes.

Well, the thread-safe list has some serious flaws exposed.  I'm not sure what you mean by 1-based.  But you are correct on removing List.RemoveAt(List.Count) if List.Count = 0 after entering the while loop will throw an exception.  My previous implementation had this return false, because it is trying to remove something that doesn't exist shouldn't do anything.  This is just like calling List.Remove(ItemNotInList) when ItemNotInList doesn't exist within the list.  But .NET's implementation of List.RemoveAt will unfortunately throw an error.

I will try to update it so this doesn't happen.

But PFX really supports thread safe collections much better (without blocking increasing parallelism).   I do, however, like the fact that this allows thread-safety to be loosely-coupled with the collections, if nothing else than for understand how thread-safety works.

Using a read-write locker for most collections is depreciated (except in regards to examples), because functionality is very well confided within them.  But for parallel access to databases, files, and native resources, I think this is a very good candidate for using.

Coordinator
Oct 7, 2010 at 8:54 AM
Edited Oct 7, 2010 at 8:55 AM

Since Monitor.Enter being used within lock/SyncLock has overhead regarding putting a thread to sleep, I plan on implementing collections (including a hybrid IBindingListView/ObservableList/ListViewCollection--supporting WPF and WinForms simultaneously) using SpinLocks.  RTU Linked Lists are tempting to implement, but it would have to be separate, as the algorithm is licensed as L-GPL.

PFX, of course, has better collections by using non-blocking techniques, but these will be useful with <= .NET 3.5 and have a few places with more functionality/backwards comparability .

Jessie Johnson's ObjectListView is the place where I first learned about ListViewCollection functionality before .NET 3.0 came out, which binds to another collection and allows sorting, filtering, and manipulating this while not affecting the underlying list--very similar to a DataView.  One limitation to ListViewCollection is that it doesn't allow adding and removing items, except by using new-line functionality found in IBindingList.

I will not only allow adding, removing, one-way and two-way syncing, and buffering changes, but I'll also design it with thread-safety in mind.  It may take quite a while, but it should support both DataTables and the Entity Framework.

But this is probably more information than you are interested in.  I like to program, but I'm not the greatest at keeping it too the point.  I hope you find this helpful anyways.