How can I send and receive messages between threads?
One solution would be share a concurrent queue, for example (albeit its name) ConcurrentQueue. This will allow you to enqueue an object from one thread and have the other thread (or others threads) dequeue from the queue. As it is a generic solution, you may pass strongly typed items, anything from string to Action will do, or your own custom message class of course.
Threre is just one limitation with this approach, the class ConcurrentQueue is only available from .NET 4.0 onwards. If you need this for a previous version of .NET you need to look for a third party libary. For example you can take the source for ConcurrentQueue from mono.
The general approach over which those queues work is by having a linked list and they resource to optimistic concurrency control using spinning for synchronization. As far as I know, this is the state of art for concurrent queues of variable size. Now, if you know the message load beforehand you can try a fixed size approach or a solution that favors enqueue and dequeue over growing (that would be an array based queue).
Full disclouser (according to faq): I'm the author of one of those third party libraries... my libraries (nuget available), it includes a backport ConcurrentQueue for old versions of .NET, based on a custom implementation. You can find the underlaying structure under Theraot.Collections.ThreadSafe.SafeQueue, it is a linked list of arrays (which are kept in an object pool), by doing it this way, we do not need to copy the arrays to grow (because we just add another node to the list), and we do not need to rely on synchronization mechanisms as often (because adding or removing an item does not modify the list often).
Note: this question used to link to HashBucket, which is hosted on another repository, and was my old solution for the problem. That project is discontinued, please use the version I mention above.
This is an old question, but still a relevant topic...
A producer/consumer approach may be used as possible solution for a problem like this. .NET Core, from version 3.0, has a namespace with tools to deal with that in a simple way.
Take a look at System.Threading.Channels:
https://learn.microsoft.com/en-us/dotnet/api/system.threading.channels
https://devblogs.microsoft.com/dotnet/an-introduction-to-system-threading-channels/
I think you are talking about Joining between threads? and this.
One way to do it is to create a class that has the method that you will call for the thread.
That class can have more than just the method; it can have members that the parent thread can have access to.
Given that, the parent can read from and write to those members, that way there is a means of communication between the two threads throughout the span of the thread's life.
There are many thread synchronization primitives you can use in .Net such as EventWaitHandle, Mutex, Semaphores etc. Here is a useful link on MSDN to find out how. - https://learn.microsoft.com/en-us/dotnet/standard/threading/overview-of-synchronization-primitives
Related
There are some cases where I really like using Guava's Striped class.
Is there an equivalent in C#?
It doesn't look like there is a direct equivalent, but there are some lockless thread-safe collection options (I'm not sure what you're trying to achieve, so I can't say if they will work for your scenario). Have a look at the System.Collections.Concurrent Namespace.
In particular, ConcurrentBag, ConcurrentQueue, ConcurrentStack, and ConcurrentDictionary all have different locking/lockless thread-safe strategies. Some are explained in this blog post.
You might be able to get what you want via the Partitioner class, although I am unsure of the implementation.
#Behrooz is incorrect in saying that all .net framework types only use a single lock for the entire list. Take a look at the source for ConcurrentDictionary. Line 71 suggests that this class is implemented using multiple locks.
If you really want to, you could write your own version. The source for the Guava Striped is: https://github.com/google/guava/blob/master/guava/src/com/google/common/util/concurrent/Striped.java
I think best you can do is implementing your own because all dotnet framework types offer only one lock for the entire list.
To do that you can use the GetHashCode() function, modulus(%) it with the number of stripes you want. and use it as an index for Tuple<TLock, List<T>>[] where TLock can be any kind of lock defined in System.Threading namespace and T is the type you want to store/access.
With this you can decide how you want your stripes to be stored. There are choices like HashSet(inefficient in your case since you already use some of the bits to calculate the stripe index), SortedSet, List, Array.
btw, Thank you for the question, It's gonna help me solve a problem I'm having.
Have you tried Tamarind from NuGet?
It's C# port of Google's Guava library
I think the ConcurrentDictionary can archive a similar result.
Based on their documentation:
All these operations are atomic and are thread-safe with regards to all other operations on the ConcurrentDictionary class. The only exceptions are the methods that accept a delegate, that is, AddOrUpdate and GetOrAdd. For modifications and write operations to the dictionary, ConcurrentDictionary uses fine-grained locking to ensure thread safety. (Read operations on the dictionary are performed in a lock-free manner.) However, delegates for these methods are called outside the locks to avoid the problems that can arise from executing unknown code under a lock. Therefore, the code executed by these delegates is not subject to the atomicity of the operation.
As you can see, read operations are lock-free. That will allow you to not block the threads from reading while other are inserting for example.
I am new to multithreading and have a question on sharing objects. I am doing this in C# .Net 4.5
I have an list that contains a object called Price. The class Price contains 12 properties one of type datetime and the others are of type double.
I then run 4 tasks which all reference this object List. None of the tasks will change the List object they are just reading from the object.
So the fact the tasks are all referencing the same object but only reading from it am I right to think that I will not need any locking?
Yes the read does not modify anything for those types (and indeed most types), so it's safe.
Until and unless you do not have update and add going on any other thread you do not need to add locking. If update or edit is going on any other thread then do consider to use locking.
ReaderWriterLockSlim provides an easy and efficient way to provide advanced Reader and Writer locks.
Moreover as mentioned in Thread Safety section in documentation,
It is safe to perform multiple read operations on a List, but issues can occur if the collection is modified while it’s being read.
I'm exploring the use of RuntimeHelpers.PrepareMethod() to reduce start-up time on thin client applications with heavy UI libraries
I created a JIT-helper class to run on a background thread and iterates through methods of a type or assembly and calls PrepareMethod on them
First of all, is there any drawback to doing this? (and I don't mean JIT-ing the entire application, I mean just heavy libraries eg Infragistics, DevExpress and classes representing window classes in WPF)
Secondly, is there anyway to determine whether or not a method has been JIT-ed already? (although I didn't notice any delay or problems from accidentally calling it multiple times)
Lastly, what happens if I do the JIT-ing on a background thread and another thread calls a method that is currently being JIT-ed?
Since what you ask is highly implementation-dependent there is no definitive answer... I would expect there to be some sort of locking on the method while it is being JITted... but other than digging deep into the specific .NET version etc. this remains speculation...
BTW: there is a (non-public) field called IsJitted on the respective MethodDesc which the JIT compiler sets to true after jitting... for some more information see here...
We have a very high performance multitasking, near real-time C# application. This performance was achieved primarily by implementing cooperative multitasking in-house with a home grown scheduler. This is often called micro-threads. In this system all the tasks communicate with other tasks via queues.
The specific problem that we have seems to only be solvable via first class continuations which C# does not support.
Specifically the problem arises in 2 cases dealing with queues. Whenever any particular task performs some work before placing an item on a queue. What if the queue is full?
Conversely, a different task may do some work and then need to take an item off of a queue. What if that queue is empty?
We have solved this in 90% of the cases by linking queues to tasks to avoid tasks getting invoked if any of their outbound queues are full or inbound queue is empty.
Furthermore certain tasks were converted into state machines so they can handle if a queue is full/empty and continue without waiting.
The real problem arises in a few edge cases where it is impractical to do either of those solutions. The idea in that scenario would be to save the stack state at the point and switch to a different task so that it can do the work and subsequently retry the waiting task whenever it is able to continue.
In the past, we attempted to have the waiting task call back into the schedule (recursively) to allow the other tasks to and later retry the waiting task. However, that led to too many "deadlock" situations.
There was an example somewhere of a custom CLR host to make the .NET threads actually operate as "fibers" which essentially allows switching stack state between threads. But now I can't seem to find any sample code for that. Plus it seems that will take some significant complexity to get it right.
Does anyone have any other creative ideas how to switch between tasks efficiently and avoid the above problems?
Are there any other CLR hosts that offer this, commercial or otherwise? Is there any add-on native library that can offer some form of continuations for C#?
There is the C# 5 CTP, which performs a continuation-passing-style transformation over methods declared with the new async keyword, and continuation-passing based calls when using the await keyword.
This is not actually a new CLR feature but rather a set of directives for the compiler to perform the CPS transformation over your code and a handful of library routines for manipulating and scheduling continuations. Activation records for async methods are placed on the heap instead of the stack, so they're not tied to a specific thread.
Nope, not going to work. C# (and even IL) is too complex language to perform such transformations (CPS) in a general way. The best you can get is what C# 5 will offer. That said, you will probably not be able to break/resume with higher order loops/iterations, which is really want you want from general purpose reifiable continuations.
Fiber mode was removed from v2 of the CLR because of issues under stress, see:
Fiber mode is gone...
Fibers and the CLR
Question to the CLR experts : fiber mode support in hosting
To my knowledge fiber support has not yet bee re-added, although from reading the above articles it may be added again (however the fact that nothing has mentioned for 6-7 years on the topic makes me believe that its unlikely).
FYI fiber support was intended to be a way for existing applications that use fibers (such as SQL Server) to host the CLR in a way that allows them to maximise performance, not as a method to allow .Net applications to create hundereds of threads - in short fibers are not a magic bullet solution to your problem, however if you have an application that uses fibers an wishes to host the CLR then the managed hosting APIs do provide the means for the CLR to "work nicely" with your application. A good source of information on this would be the managed hosting API documentation, or to look into how SQL Server hosts the CLR, of which there are several highly informative articles around.
Also take a quick read of Threads, fibers, stacks and address space.
Actually, we decided on a direction to go with this. We're using the Observer pattern with Message Passsing. We built a home grown library to handle all communication between "Agents" which are similar to an Erlang process. Later we will consider using AppDomains to even better separate Agents from each other. Design ideas were borrowed from the Erlang programming language which has extremely reliable mult-core and distributed processing.
The solution to your problem is to use lock-free algorithms allowing for system wide progress of at least one task. You need to use inline assembler that is CPU dependent to make sure that you atomic CAS (compare-and-swap). Wikipedia has an article as well as patterns described the the book by Douglas Schmidt called "Pattern-Oriented Software Architecture, Patterns for Concurrent and Networked Objects". It is not immediately clear to me how you will do that under the dotnet framework.
Other way of solving your problem is using the publish-subscriber pattern or possible thread pools.
Hope this was helpful?
I have been searching lately for information on how to construct a lock-free priority queue in C#. I have yet to even find an implementation in any language, or a decent paper on the matter. I have found several papers which appear to be copies or at least referencing one particular paper which is not actually a paper on lock free priority queues, despite its name; it is in fact a paper on a priority queue which uses fine grained locks.
The responses I have been receiving from elsewhere include "use a single thread" and "you do not need it to be lock free" and "it is impossible". All three of these responses are incorrect.
If someone has some information on this, I would greatly appreciate it.
Generally, it's a bad idea to write this kind of code yourself.
However, if you really want to write this kind of code, I say take a page from Eric Lippert's book (or blog, as it were) (web archive link), where basically, you would implement the queue but instead of having all the functions that make modifications on the queue modify the instance you call the method on, the methods return completely new instances of the queue.
This is semantically similar to the pattern that System.String uses to maintain immutability; all operations return a new System.String, the original is not modified.
The result of this is that you are forced to reassign the reference returned on every call. Because the assignments of references are atomic operations, there is no concern about thread-safety; you are guaranteed that the reads/writes will be atomic.
However, this will result in a last-in-wins situation; it's possible that multiple modifications are being made to the queue, but only the last assignment will hold, losing the other insertions into the queue.
This might be acceptable; if not, you have to use synchronization around the assignment and reading of the reference. You will still have a lock-free-priority queue, but if you have concerns about thread-safety and maintaining the integrity of the operations, you have done nothing but move the concern about synchronization outside of the data structure (which is almost all cases, is a good thing, as it gives you fine-grained explicit control).
The Art of Multiprocessor Programming. Look at Chapter 15 - Priority Queues. Book is in Java, but can be easily translated to C# since they both have GC (which is important for most implementations in the book).