31

Does anyone know if there are any lock-free container libraries available for .NET ?

Preferably something that is proven to work and faster than the Synchronized wrappers we have in .NET.

I have found some articles on the .NET, but none of them specify any speed benchmarking, nor do they inspire much confidence in their reliability.

Thanks

Constantin
  • 27,478
  • 10
  • 60
  • 79
Radu094
  • 28,068
  • 16
  • 63
  • 80
  • 3
    Please follow up and post any performance related data you may have found on the lock free structures you might have tested. – Jason Short Feb 25 '09 at 21:31
  • 2
    We ended-up rolling our own containers, largelly based from http://www.boyet.com/index.html. Using lock-free versus standard containers we had a marginal (on average) decrease of ~12% of the total time needed to process our sample batch. All in all I would say it was not worth the effort :-( – Radu094 Apr 27 '09 at 07:14
  • 1
    I came across [Ariadne](http://hackcraft.github.io/Ariadne/) which has these. I'm having difficulty understanding the code though. It has some quirky empty for statements like `for(;;){...some code...}` and it will have a return statement inside there. It has a comment at the top stating: "This queue is mostly for completion or for use in other classes in the library, considering that the 4.0 FCL already has a lock-free queue. The Mono implementation is very close to this, while the MS implementation is more complicated but should offer better use of CPU caches..." – Louis Somers May 28 '13 at 20:10
  • 2
    @LouisSomers I'm not so much quirky as old-fashioned; that used to be a popular style for an infinite loop (or one that breaks on something other than conditions in the loop definition) though `while(true)` is perhaps more popular today the former reads to me as "for ever" while the latter as "while basic-logical-rules-of-the-universe-hold", which disturbs me slightly. I did add some functionality beyond the FCL since that comment, I should edit it, but I think I'll save that until a more thorough review later this year. – Jon Hanna Jan 17 '14 at 17:57
  • @Jon, Thanks for explaining and sorry for calling your code quirkey. `While(true)` certainly reads easier for me, but in the end these kinds of libs are rather optimized for performance than for readability so I should not have judged it on readability in the first place (forgot to switch gears there). – Louis Somers Jan 18 '14 at 11:56
  • 1
    @LouisSomers I'm cool with "quirky", there are some bits of that code in that library that are indeed quirky for speed (`goto` in hand-coded tail-call elimination) or quirky because the state-transitions are unusual compared to what would be natural if concurrency didn't have to be considered. `while(true)` and `for(;;)` though are exactly the same, it's purely a matter of style. `for(;;)` is used in K&R and Stroustrup's C++ book but `while(true)` became more popular later on, so `for(;;)` is just more old-fashioned. (Also some older tools will complain about the constant, though not in C#)... – Jon Hanna Jan 18 '14 at 12:11
  • 1
    @LouisSomers it quite possibly is historically related to performance concerns, as a literal interpretation of `while(true)` would take a true value, and then examine it to see if it was true, while `for(;;)` was designed from the beginning to skip those parts left out, back in the early days of C. I'd be pretty shocked at any compiler that didn't treat them exactly the same today though, or any time after about the mid-80s for that matter. – Jon Hanna Jan 18 '14 at 12:15

4 Answers4

17

Late, but better than never I thought I would add Julian Bucknalls articles to this list.

But he does not have performance numbers. In my testing of his structures the list scaled well compared to locking (very low kernel usage compared to ReaderWriterLock).

His blog has a series of articles on lock free structures in C#.

LOCK-FREE DATA STRUCTURES: THE STACK

Jason Short
  • 5,205
  • 1
  • 28
  • 45
  • Kernel usage has nothing to do with CAS that he is utilising. CAS is a heavyweight hammer but in CLR you pretty much don't have many options, for now. – rama-jka toti Mar 16 '09 at 23:30
  • CAS is light on kernel time compared to ReaderWriterLock. Compare the two in loops. One will use all user space time, the other all kernel time. – Jason Short Mar 23 '09 at 16:30
  • 1
    You can't actually do a lock-free stack, unless you know, a priori, that your elements will not be deleted. C# I believe does garbage collection (which takes away some of the point of using lock-free!) so you get away with it. But in C, I believe that stack is broken, with the normal bug in pop. –  Apr 01 '09 at 21:15
  • BTW, my comment about the stack being broken is utterly wrong. –  Oct 17 '09 at 10:17
  • 1
    @Blank Xavier. Not utterly. If you were to do a naïve port to C or C++ it would be broken, and it would be hard to do a "proper" port because you've got to find some way to handle what the C# can depend on the GC handling. So yes, your comment was wrong, but not "utterly" wrong as it does address an important point about what runtime conditions the algorithm depends on. – Jon Hanna Aug 31 '10 at 12:11
  • Silly rabbits. GC is optional in C#. Simply keep references and they'll never get collected. So you can keep your on pool of objects and reuse them. Very typical solution for performance because even in C and C++ the malloc() and new operators are costly operations. Regardless if the framefreeks "frees" the space or the programmer does it manually...it's too expensive to contemplate in high performance apps. – Wayne Dec 22 '11 at 00:55
11

Do you mean the container classes like they exist in the PFX framework (Parallels for .NET), ConcurrentQueue & ConcurrentStack

Pfx blog

Frederik Gheysels
  • 56,135
  • 11
  • 101
  • 154
  • PFX looks good, but the documentation would seem to imply that ConcurrentQueue and ConcurrentStack use locks to provide thread-safety – Radu094 Feb 15 '09 at 12:32
  • I'd avoid PFX at all costs. We saw an 8-fold (that's right) degradation before realising it really isn't going to give you anything a good book will not teach you to do better.. – rama-jka toti Mar 16 '09 at 23:33
  • @Radu094: Joe Duffy's book "Concurrent Programming on Windows" states that the `ConcurrentQueue` is currently lock free. @rama-jka toti: The stuff in .NET 4 is much better than the CTP's were but I haven't tested the lock free data structures against alternatives. They are still much slower than their thread-unsafe counterparts, of course. – J D Jun 15 '10 at 19:13
  • There's a good discussion here which implies that writing (adding to) the concurrent collections is slower and uses locking, but reading from them does not and is faster... http://www.albahari.com/threading/part5.aspx#_Concurrent_Collections – dodgy_coder Apr 19 '12 at 04:02
  • @dodgy_coder That article considers the case of one writer, multiple readers. In the case of multiple writers, multiple readers I'd expect the concurrent collection to be much faster to write as well. – Chuu Jan 17 '14 at 17:20
1

Without knowing anything about it, there is one library I stumbled across here.

Though probably not quite what you are looking for, at least there is an implementation and discussion on StackOverflow of a lock free queue structure in C# here. Going through the StackOverflow code review process might give some confidence about its safety, or provide information about how to go about building your lock-free containers yourself.

Community
  • 1
  • 1
cdiggins
  • 17,602
  • 7
  • 105
  • 102
-5

Lock free data structures are going to have issues until they modify the CLR with the mess caused by memory models, see the CLI spec.

Lock-free programming is sufficiently difficult that you shouldn't bother with it on a collection (container) level btw. True for any language out there..

rama-jka toti
  • 1,404
  • 10
  • 16
  • 3
    Can you elaborate on "modify the CLR"? What do you think is wrong? – J D Jun 15 '10 at 19:13
  • 1
    he tries to imply the guarantees made by CLR is weak enough. though CLR memory model is not straighforward to grasp and may cause complexities, it doesnt mean we cant design bulletproof containers. – TakeMeAsAGuest Feb 15 '19 at 04:24