Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am reading Concurrency in C# Cookbook and the book told me that:
ConcurrentDictionary<TKey, TValue> is best when you have multiple
threads reading and writing to a shared collection. If the updates are
not constant (if they’re more rare), than ImmutableDictionary<TKey,TValue>
may be a better choice.
I know that Add or Remove a large immutable collection can be slow, and my question is, is there any other difference between them? Now that they are all thread safe, why is ImmutableDictionary a better choice when the updates are not constant?
These two classes ConcurrentDictionary and ImmutableDictionary were compared just because of the simple reason, both are thread safe.
However, it is not a good idea to use ImmutableDictionary for multi-threading. It is designed to represent data which should be loaded once, and shouldn't be changed / modified later on. Any modifications would lead to creating new instance of ImmutableDictionary, which is not really efficient.
Immutable can't be changed, i.e. no add/remove can alter existing dictionary, rather would create a new one shipping all but deleted item. Concurrency proceeds on the lock { } statement which has nothing to do with immutability. Locks are necessary to manage write operations done by more than single thread to the same memory piece (i.e. same object).
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I am working on implementing threading to my C# program. Each thread requires access to the same array, but does not need to write to it, only read data. Should this array be deep copied for each thread?
The reason I think this might be important (from my very limited knowledge of threading) is so that threads on different CPU cores can store copies of the array in their own cache instead of constantly requesting data from a single core's cache where the array is stored, but perhaps the compiler or something else will optimise away this inefficiency?
Any insight would be much appreciated.
Since you haven't specified the hardware architecture you are running on I'm going to assume it is either and Intel or AMD x64 processor. In which case I recommend trusting the processor to correctly optimize this situation. By creating multiple copies that the processor that the compiler can't know are duplicate copies you will force the processor to use more memory and spread the available cache space over more memory lessening it's effectiveness.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Hi what will be the cleanest solution for the following pattern ?
Given a class for Read and Write some file/resouce, providing already implemented "read()" and "write()" functions. Create a "Read()" and "Write()" function that would wrap the "read()" and "write()"and prevent threads from interfering as follows:
a. multiple threads are allowed to Read
b. Only one thread is allowed to Write - so if a thread is already writing the other threads must wait.
c. writing must be prevented while a thread is reading and vice versa
Use ReaderWriterLockSlim (https://msdn.microsoft.com/en-us/library/system.threading.readerwriterlockslim(v=vs.110).aspx) as the most efficient construct.
Quote from MSDN:
ReaderWriterLockSlim is similar to ReaderWriterLock, but it has simplified rules for recursion and for upgrading and downgrading lock state. ReaderWriterLockSlimavoids many cases of potential deadlock. In addition, the performance of ReaderWriterLockSlim is significantly better than ReaderWriterLock. ReaderWriterLockSlim is recommended for all new development.
As indicated in the comments, there's already a well-established pattern to solve this - reader-writer locks. This pattern works exactly how you describe - at any given time, you can have either an arbitrary number of readers or a single writer.
The .NET Framework already has an implementation of this pattern.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
In C#, how expensive it is to create a new class instance?
I'm speaking in context of using C# in unity3d. Meaning that stuff continuously gets called many times per second.
In C++, generally speaking (while making games) you may want to reuse anything you created with new/smart pointers, you would want to keep allocated resizeable buffers/lists/fifos and you may want to avoid that uses dynamic memory allocation (and stick to local variables) if code is getting performance critical.
So, what is the recommended way to do it in C#? Is it a very bad idea to create a new List, return it from the function and then "forget" about it, never using it again?
P.S. I'm aware of profiling and "premature optimizations", but I'd like to know some generic guidelines for the language before I (possibly) make a big mess because I used the wrong approach.
I remember reading a fun post Performance numbers in the pub by Ayendy Rahien.
How many CLR objects can you create in one second?
And here was the result back in 2011
Created 7,715,305 in 00:00:01
Jokes aside. Create is pretty cheap operation but GC is not. So while you can create really many objects, it is the collect that will hurt performance. So a rule of objects reuse can apply to C# as well.
I'd assume, but can be wrong, implementation of a new operator is located in JIT
aloc.h
aloc.cpp
As usual, avoid premature optimisation till you need it.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Is it the same if I used ConcurrentBag (to handle scenario of one writer & multiple readers) instead of using ReaderWriterLockSlim on a List<> ??
UPDATE 1:
The scenario is that there are multiple threads that can reach a static list and some may need to read others may need to write, what I want is:
1- Allow only one thread to add\edit\delete from the list while there are no other threads trying to adding\editing\deleting on it.
2- Allow many threads to read from it at the same time if there's no thread adding\editing\deleting.
In your scenario it sounds like you should be using a ReaderWriterLockSlim on a list.
A concurrent bag does not support deleting (at all) and editing is not safe.
Locking a list with a ReaderWriterLockSlim will allow safe deletion and will allow safe editing provided the editing is done within the write lock scope.
Even though both constructs are related to synchronization and threading they are definitely not interchangeable.
ConcurrentBag is a collection which you can add, take, peek and (most importantly) enumerate in a thread safe way.
ReaderWriterLockSlim is a synch object which allows to read lock or write lock on whatever you want.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I have a relatively small dictionary (a few hundred entries at most) that is receiving many calls (hundreds, possibly thousands per second) and many of them requires entry modification.
Performance wise, which one of this solution is generally recommended for a small list with frequent updates?
unboxing-boxing structs
define structure methods for each parameter that requires modification
use classes, that can be directly modified because they are referenced unlike structures
You should really avoid mutable value types (i.e. structures that can be modified) if at all possible, as it basically breaks the concept of a "value type" if one or more attributes of a value are not intrinsically part of the value itself (and thus can't be changed). If you need to store values that can be changed, then you should be using a class.