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.
Related
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).
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 5 years ago.
Improve this question
Ok, this subject is probably done to death but I wanted to throw it out there to see what people thought of my approach.
I need to create a simple WinForms application that will consist of a handle of forms. There will be variables that I can stick into the app.config as they'll never really change. However there will be some variables that are pulled in from a database unique to the user thats logging in. It's these variables that I need to persist and make available to the rest of the application to drive appropriate business logic.
Based on other articles on StackOverflow my plan would be to use the singleton pattern with IoC. So first instantiating a class based on the singleton pattern which is hooked up to an interface. The instantiated object would then be passed into the constructer of other methods in program.cs where I'll arrange most of my objects. This should mean I can easily test and mock this and other classes (I think?).
I've seen there are two ways of creating a class based on the singleton pattern, one that is the 'classic' way of doing it but isn't thread safe. The other requires slightly more coding but would be thread safe. My WinForms project would be pretty simplistic and wouldn't require multiple operations running in the background. Just simple CRUD operations fired off from the UI. For ease, I thought I'd use the classic singleton (non-thread safe) approach. That said, is that a bad thing to do, even for the most simplest of WinForm apps?
If you're using .NET 4.0+, just use Lazy<T> class for your singletons. If you insist on not caring about thread safety (why though?), get => _value ?? (_value = GetValue()) is enough.
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 want to use ThreadStatic atrribute in my code. I want to know if there will be some performance issue in IIS if I use ThreadStatic attribute in my application as multiple threads are going to access those fields . So I want to get idea if the resources of IIS are overused or any another thing I should keep in mind before implementing this.
There is no direct performance issue using ThreadStatic through IIS, but you have to take in consideration that IIS use a thread pool.
It means that your thread static is not free after a single call.
In an other hand, a web request can be composed by multiple threads executions (page for example but not web service) and may not share the same thread for a same "client request".
If you don't free yourself the ThreadStatic thing, it may cost memory usage.
If you valuate a ThreadStatic in a synchronous method that call only synchronous process and free it in a finally block at end of the same method, you can use it without any side effect.
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.