I have a Queue of items I want to process in a thread, and any instance of a class can add items to the Queue to be processed.
My idea for doing this is to have a static Thread in the class that processes the items, the only problem is that I don't know where to start this thread, since I can't start it in its initialization.
Is there a way I can start a static thread? Or should I be changing the architecture completely?
You can start it in the static constructor for the class:
private class MyClass
{
static MyClass()
{
// start thread here
}
}
You could also start it in the regular constructor of the class using a typical singleton approach.
Or you could use the new .NET 4 Lazy<T> approach to instantiating and starting it.
BUT it's generally not a good practice to do work in class constructors. A better approach would be to ensure the thread exists only when someone calls, say Execute() on an instance of the class. Within the Execute method you can use Lazy<T> or a singleton approach to creating and starting the single thread instance that will process it.
Purists will point out that actually you probably don't want to do this at all and that a Factory approach may be better for creating instances of your class and that you should separate the concerns between your class and the worker that processes it.
Other would suggest that you don't need a thread here at all, just use .NET4 Tasks and queue the items up for execution using the framework provided queue/execute methods.
Give the static queue class that you have a private inner class that handles the actual threading:
static class QueueStatic
{
public static Queue<Object> queue;
private static QueueWorker worker;
public static void DoQueueAction()
{
worker = new QueueWorker(queue);
ThreadStart t = new ThreadSTart(worker.Work);
t.Start();
}
//inner class
private class QueueWorker
{
private Queue<Object> queue;
public QueueWorker(Queue<Object> queue)
{
this.queue = queue;
}
public void Work()
{
//...
}
}
}
Related
In other words, is this Singleton implementation thread safe:
public class Singleton
{
private static Singleton instance;
private Singleton() { }
static Singleton()
{
instance = new Singleton();
}
public static Singleton Instance
{
get { return instance; }
}
}
Static constructors are guaranteed to be run only once per application domain, before any instances of a class are created or any static members are accessed. https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/static-constructors
The implementation shown is thread safe for the initial construction, that is, no locking or null testing is required for constructing the Singleton object. However, this does not mean that any use of the instance will be synchronised. There are a variety of ways that this can be done; I've shown one below.
public class Singleton
{
private static Singleton instance;
// Added a static mutex for synchronising use of instance.
private static System.Threading.Mutex mutex;
private Singleton() { }
static Singleton()
{
instance = new Singleton();
mutex = new System.Threading.Mutex();
}
public static Singleton Acquire()
{
mutex.WaitOne();
return instance;
}
// Each call to Acquire() requires a call to Release()
public static void Release()
{
mutex.ReleaseMutex();
}
}
While all of these answers are giving the same general answer, there is one caveat.
Remember that all potential derivations of a generic class are compiled as individual types. So use caution when implementing static constructors for generic types.
class MyObject<T>
{
static MyObject()
{
//this code will get executed for each T.
}
}
EDIT:
Here is the demonstration:
static void Main(string[] args)
{
var obj = new Foo<object>();
var obj2 = new Foo<string>();
}
public class Foo<T>
{
static Foo()
{
System.Diagnostics.Debug.WriteLine(String.Format("Hit {0}", typeof(T).ToString()));
}
}
In the console:
Hit System.Object
Hit System.String
Using a static constructor actually is threadsafe. The static constructor is guaranteed to be executed only once.
From the C# language specification:
The static constructor for a class executes at most once in a given application domain. The execution of a static constructor is triggered by the first of the following events to occur within an application domain:
An instance of the class is created.
Any of the static members of the class are referenced.
So yes, you can trust that your singleton will be correctly instantiated.
Zooba made an excellent point (and 15 seconds before me, too!) that the static constructor will not guarantee thread-safe shared access to the singleton. That will need to be handled in another manner.
Here's the Cliffnotes version from the above MSDN page on c# singleton:
Use the following pattern, always, you can't go wrong:
public sealed class Singleton
{
private static readonly Singleton instance = new Singleton();
private Singleton(){}
public static Singleton Instance
{
get
{
return instance;
}
}
}
Beyond the obvious singleton features, it gives you these two things for free (in respect to singleton in c++):
lazy construction (or no construction if it was never called)
synchronization
Static constructors are guaranteed to fire only once per App Domain so your approach should be OK. However, it is functionally no different from the more concise, inline version:
private static readonly Singleton instance = new Singleton();
Thread safety is more of an issue when you are lazily initializing things.
The static constructor will finish running before any thread is allowed to access the class.
private class InitializerTest
{
static private int _x;
static public string Status()
{
return "_x = " + _x;
}
static InitializerTest()
{
System.Diagnostics.Debug.WriteLine("InitializerTest() starting.");
_x = 1;
Thread.Sleep(3000);
_x = 2;
System.Diagnostics.Debug.WriteLine("InitializerTest() finished.");
}
}
private void ClassInitializerInThread()
{
System.Diagnostics.Debug.WriteLine(Thread.CurrentThread.GetHashCode() + ": ClassInitializerInThread() starting.");
string status = InitializerTest.Status();
System.Diagnostics.Debug.WriteLine(Thread.CurrentThread.GetHashCode() + ": ClassInitializerInThread() status = " + status);
}
private void classInitializerButton_Click(object sender, EventArgs e)
{
new Thread(ClassInitializerInThread).Start();
new Thread(ClassInitializerInThread).Start();
new Thread(ClassInitializerInThread).Start();
}
The code above produced the results below.
10: ClassInitializerInThread() starting.
11: ClassInitializerInThread() starting.
12: ClassInitializerInThread() starting.
InitializerTest() starting.
InitializerTest() finished.
11: ClassInitializerInThread() status = _x = 2
The thread 0x2650 has exited with code 0 (0x0).
10: ClassInitializerInThread() status = _x = 2
The thread 0x1f50 has exited with code 0 (0x0).
12: ClassInitializerInThread() status = _x = 2
The thread 0x73c has exited with code 0 (0x0).
Even though the static constructor took a long time to run, the other threads stopped and waited. All threads read the value of _x set at the bottom of the static constructor.
The Common Language Infrastructure specification guarantees that "a type initializer shall run exactly once for any given type, unless explicitly called by user code." (Section 9.5.3.1.) So unless you have some whacky IL on the loose calling Singleton::.cctor directly (unlikely) your static constructor will run exactly once before the Singleton type is used, only one instance of Singleton will be created, and your Instance property is thread-safe.
Note that if Singleton's constructor accesses the Instance property (even indirectly) then the Instance property will be null. The best you can do is detect when this happens and throw an exception, by checking that instance is non-null in the property accessor. After your static constructor completes the Instance property will be non-null.
As Zoomba's answer points out you will need to make Singleton safe to access from multiple threads, or implement a locking mechanism around using the singleton instance.
Although other answers are mostly correct, there is yet another caveat with static constructors.
As per section II.10.5.3.3 Races and deadlocks of the ECMA-335 Common Language
Infrastructure
Type initialization alone shall not create a deadlock unless some code
called from a type initializer (directly or indirectly) explicitly
invokes blocking operations.
The following code results in a deadlock
using System.Threading;
class MyClass
{
static void Main() { /* Won’t run... the static constructor deadlocks */ }
static MyClass()
{
Thread thread = new Thread(arg => { });
thread.Start();
thread.Join();
}
}
Original author is Igor Ostrovsky, see his post here.
Just to be pedantic, but there is no such thing as a static constructor, but rather static type initializers, here's a small demo of cyclic static constructor dependency which illustrates this point.
Static constructor is guaranteed to be thread safe.
Also, check out the discussion on Singleton at DeveloperZen:
http://web.archive.org/web/20160404231134/http://www.developerzen.com/2007/07/15/whats-wrong-with-this-code-1-discussion/
The static constructor is locked. While the type initializer is running, any other thread which attempts to access the class in such a way that would trigger the type initializer will block.
However, the thread which is running the type initializer can access uninitialized static members. So be sure not to call Monitor.Enter() (lock(){}) or ManualResetEventSlim.Wait() from a type initializer if it is run from a UI thread—those are “interruptible” waits which result in the event loop running, executing arbitrary other parts of your program while your type initializer is still unfinished.
It is preferable for you to use managed blocking rather than unmanaged blocking. WaitHandle.WaitOne, WaitHandle.WaitAny, WaitHandle.WaitAll, Monitor.Enter, Monitor.TryEnter, Thread.Join, GC.WaitForPendingFinalizers, and so on are all responsive to Thread.Interrupt and to Thread.Abort. Also, if your thread is in a single-threaded apartment, all these managed blocking operations will correctly pump messages in your apartment while your thread is blocked:
I have been given an application that boils down to being a producer-consumer pattern. Several threads are doing some work and updating a single data set so that several more threads can consume that data and do their own work with it. At the moment, it's not terribly complex, all the consuming threads wait on the data set until one of the producers calls a pulseall.
There is now a desire to have one of the consumer threads consume from two different data sets anytime either of the sets changes. The teams desire to keep refactoring to a minimum and my limited experience with threading has given me some issues finding a clean solution.
The quick and dirty solution was to do the waiting and pulsing on a separate object and have the consumer threads check for changes in their data set before continuing. There does not seem to be a way for one thread to wait on two objects, without replacing the generic threads with a more robust threading tool (thread pools, task, etc) unless I'm failing to google the right thing.
If you are willing to do a little refactoring I would recommend switching from Monitor to one of the EventWaitHandle derived classes.
Depending on the behavior you want you may want AutoResetEvent, that will more closely act like a Monitor.Entier(obj)/Monitor.Exit(obj)
private readonly object _lockobj = new Object();
public void LockResource()
{
Monitor.Enter(_lockobj);
}
public void FreeResource()
{
Monitor.Exit(_lockobj);
}
//Which is the same as
private readonly AutoResetEvent _lockobj = new AutoResetEvent(true);
public void LockResource()
{
_lockobj.WaitOne();
}
public void FreeResource()
{
_lockobj.Set();
}
or you may want ManualResetEvent will more closely act like Monitor.Wait(obj)/Monitor.PulseAll(obj)
private readonly object _lockobj = new Object();
public void LockResource()
{
Monitor.Enter(_lockobj);
}
public bool WaitForResource()
{
//requires to be inside of a lock.
//returns true if it is the lock holder.
return Monitor.Wait(_lockobj);
}
public void SignalAll()
{
Monitor.PulseAll(_lockobj);
}
// Is very close to
private readonly ManualResetEvent _lockobj = new ManualResetEvent(true);
public bool LockResource()
{
//Returns true if it was able to perform the lock.
return _lockobj.Reset();
}
public void WaitForResource()
{
//Does not require to be in a lock.
//if the _lockobj is in the signaled state this call does not block.
_lockobj.WaitOne();
}
public void SignalAll()
{
_lockobj.Set();
}
1 event can wake up multiple threads, to handle multiple events by one thread you can do
ManualResetEvent resetEvent0 = ...
ManualResetEvent resetEvent1 = ...
public int WaitForEvent()
{
int i = WaitHandle.WaitAny(new WaitHandle[] {resetEvent0, resetEvent1});
return i;
}
and i will be the index of the reset event that had Set() called on it.
In c#, the main class created a Logger object that will be accessed by many threads. The logger object looks like (simplified)
public sealed class Logger
{
private ConcurrentQueue<string> queue = new ConcurrentQueue<string>();
public Logger()
{
// create other objects here AND a thread that extracts
// from the queue and writes to a file
// because queue is thread safe this is perfectly ok
}
public void Log(string whatToLog)
{
// Now, is this safe? This method will be called by several threads
// perhaps at the same time
string s = whatToLog + " " + DateTime.Now.ToString();
queue.Enqueue(s);
// The thread created in the constructor will extract and log
}
}
Is this OK from a design point of view? My two questions are:
Is "string s = whatToLog + " " + DateTime.Now.ToString();" ok if this method is accessed by several threads at the same time? I guess yes because any thread will have its own copy of s, right?
If the Logger object is accessed by several threads at the same time using only the Log() method, is everything safe then?
Thanks
The class is pretty thread safe.
Some suggested improvements.
The class doesn't prevent multiple instances from being instantiated, which is important if you want to have all threads log to the same object. Perhaps the singleton pattern could be applied. Quick example of a pseudo singleton using a static constructor. Please note the default constructor is private preventing any other class from creating a logger.
A performance related change is to avoid concatenating strings when logging. Creating new string is not a cheap operation. Also, once DateTime.Now is converted to a string, it is much harder to evaluate. E.g. sorting messages by creation date and time, etc. In the following, whatToLog is paired up with DateTime.Now in a Tuple.
public sealed class Logger
{
public static Logger instance {get; private set;}
static Logger()
{
instance = new Logger();
}
private ConcurrentQueue<Tuple<string, DateTime>> queue = new ConcurrentQueue<Tuple<string, DateTime>>();
private Logger() {}
public void Log(string whatToLog)
{
queue.Enqueue(new Tuple(whatToLog, DateTime.Now));
}
}
The ConcurrentQueue will make sure that the queue-part will be thread safe.
The string s you construct will not make it more or less thread-safe
In the current form, you should instantiate the logger, and pass the reference to each thread that will use this class
Although thread-safe, it does not guarantee sequentiality of the items
Queues cannot grow infinitely, make sure that your mechanism to dequeue can keep up
Improvements:
Make the class static, easier access for several threads
Separate concerns on reading and writing; this can be done by making several essential function internal and placing classes in the same namespace
use C#6 string interpolation
Code with improvements
public static class Logger
{
private static ConcurrentQueue<string> queue = new ConcurrentQueue<string>();
public static void Log(string LogMessage)
{
// thread safe logging
queue.Enqueue($"{LogMessage} {DateTime.Now}");
}
//dequeue only within namespace
internal static string Dequeue() {
string dequeuedItem;
queue.TryDequeue(out dequeuedItem);
return dequeuedItem;
}
}
public class LoggerReader
{
public LoggerReader()
{
// create other objects here AND a thread that extracts
// from the queue and writes to a file
// because queue is thread safe this is perfectly ok
string logItem = Logger.Dequeue();
}
}
I would simply use a lock in the Log method (replace ConcurrentQueue by Queue), and would not worry about each instruction anymore, especially if the original logger is more complicated than the example here!
public void Log(string whatToLog)
{
lock(queue) {
string s = whatToLog + " " + DateTime.Now.ToString();
queue.Enqueue(s);
}
}
Consider the following pseudo code.
static class Tools
{
static readonly UnmanagedType ut = new UnmanagedType ();
}
What is the best pattern for this scenario such that the unmanaged static instance can be guaranteed to get released to the system right after the application exits?
My rough idea is to compulsorily subscribe Tools disposing method to the system's close event right after ut is instantiated in Tools class. Is it possible? How?
Singleton?
sealed class Tools
{
public static readonly Tools Instance = new Tools();
private UnmanagedType ut = new UnmanagedType ();
~Tools() {
// TODO: destroy this.ut
}
}
I have seen several answers to the similar questions (i.e. “How to release/dispose objects/resources in static class once a process exits”). All the answers basically state that
a) static class in C# cannot have destructor (which is correct),
b) and therefore you cannot release resources at the end of static class life,
c) hence you MUST turn your class to non-static to dispose/release objects/resources.
I disagree with the items b) and c) and suggest the following solution for disposing the objects in static class on exit:
In your static class constructor or any first call to its method that creates the object(s) to dispose:
a) save a main process thread reference (Thread.CurrentThread);
b) start a new thread (Watcher) that monitors whether the main thread is running.
Once the main thread dies, the Watcher disposes/releases the objects/resources and exits.
Example code:
using System.Threading;
public static class StaticDisposer
{
private static Thread mParentProcThread = null;
private static Thread mDisposerThread = null;
// Other class members:
………………………………………………
// Objects to be disposed at the process exit:
// Ex.: private/public static … obj1ToDispose = null;
………………………………………………
static StaticDisposer()
{
mParentProcThread = Thread.CurrentThread;
mDisposerThread = new Thread(DisposerThreadBody);
mDisposerThread.Start();
}
// Methods of the class:
………………………………………………
private static void DisposerThreadBody()
{
while (mParentProcThread != null && mParentProcThread.IsAlive)
{
Thread.Sleep(500);
}
// Dispose objects, release resources, close streams, delete temporary files, etc.:
//if(obj1ToDispose != null)
// <Dispose code>
// ………………………………………………………………………………
}
}
NB! If you have several threads in your program that are using your static class with the suggested disposing logic and you want the disposing to happen only when the main thread stops, then the main thread MUST call/set/get any method/property of the static class before the secondary threads do.
In other words, is this Singleton implementation thread safe:
public class Singleton
{
private static Singleton instance;
private Singleton() { }
static Singleton()
{
instance = new Singleton();
}
public static Singleton Instance
{
get { return instance; }
}
}
Static constructors are guaranteed to be run only once per application domain, before any instances of a class are created or any static members are accessed. https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/static-constructors
The implementation shown is thread safe for the initial construction, that is, no locking or null testing is required for constructing the Singleton object. However, this does not mean that any use of the instance will be synchronised. There are a variety of ways that this can be done; I've shown one below.
public class Singleton
{
private static Singleton instance;
// Added a static mutex for synchronising use of instance.
private static System.Threading.Mutex mutex;
private Singleton() { }
static Singleton()
{
instance = new Singleton();
mutex = new System.Threading.Mutex();
}
public static Singleton Acquire()
{
mutex.WaitOne();
return instance;
}
// Each call to Acquire() requires a call to Release()
public static void Release()
{
mutex.ReleaseMutex();
}
}
While all of these answers are giving the same general answer, there is one caveat.
Remember that all potential derivations of a generic class are compiled as individual types. So use caution when implementing static constructors for generic types.
class MyObject<T>
{
static MyObject()
{
//this code will get executed for each T.
}
}
EDIT:
Here is the demonstration:
static void Main(string[] args)
{
var obj = new Foo<object>();
var obj2 = new Foo<string>();
}
public class Foo<T>
{
static Foo()
{
System.Diagnostics.Debug.WriteLine(String.Format("Hit {0}", typeof(T).ToString()));
}
}
In the console:
Hit System.Object
Hit System.String
Using a static constructor actually is threadsafe. The static constructor is guaranteed to be executed only once.
From the C# language specification:
The static constructor for a class executes at most once in a given application domain. The execution of a static constructor is triggered by the first of the following events to occur within an application domain:
An instance of the class is created.
Any of the static members of the class are referenced.
So yes, you can trust that your singleton will be correctly instantiated.
Zooba made an excellent point (and 15 seconds before me, too!) that the static constructor will not guarantee thread-safe shared access to the singleton. That will need to be handled in another manner.
Here's the Cliffnotes version from the above MSDN page on c# singleton:
Use the following pattern, always, you can't go wrong:
public sealed class Singleton
{
private static readonly Singleton instance = new Singleton();
private Singleton(){}
public static Singleton Instance
{
get
{
return instance;
}
}
}
Beyond the obvious singleton features, it gives you these two things for free (in respect to singleton in c++):
lazy construction (or no construction if it was never called)
synchronization
Static constructors are guaranteed to fire only once per App Domain so your approach should be OK. However, it is functionally no different from the more concise, inline version:
private static readonly Singleton instance = new Singleton();
Thread safety is more of an issue when you are lazily initializing things.
The static constructor will finish running before any thread is allowed to access the class.
private class InitializerTest
{
static private int _x;
static public string Status()
{
return "_x = " + _x;
}
static InitializerTest()
{
System.Diagnostics.Debug.WriteLine("InitializerTest() starting.");
_x = 1;
Thread.Sleep(3000);
_x = 2;
System.Diagnostics.Debug.WriteLine("InitializerTest() finished.");
}
}
private void ClassInitializerInThread()
{
System.Diagnostics.Debug.WriteLine(Thread.CurrentThread.GetHashCode() + ": ClassInitializerInThread() starting.");
string status = InitializerTest.Status();
System.Diagnostics.Debug.WriteLine(Thread.CurrentThread.GetHashCode() + ": ClassInitializerInThread() status = " + status);
}
private void classInitializerButton_Click(object sender, EventArgs e)
{
new Thread(ClassInitializerInThread).Start();
new Thread(ClassInitializerInThread).Start();
new Thread(ClassInitializerInThread).Start();
}
The code above produced the results below.
10: ClassInitializerInThread() starting.
11: ClassInitializerInThread() starting.
12: ClassInitializerInThread() starting.
InitializerTest() starting.
InitializerTest() finished.
11: ClassInitializerInThread() status = _x = 2
The thread 0x2650 has exited with code 0 (0x0).
10: ClassInitializerInThread() status = _x = 2
The thread 0x1f50 has exited with code 0 (0x0).
12: ClassInitializerInThread() status = _x = 2
The thread 0x73c has exited with code 0 (0x0).
Even though the static constructor took a long time to run, the other threads stopped and waited. All threads read the value of _x set at the bottom of the static constructor.
The Common Language Infrastructure specification guarantees that "a type initializer shall run exactly once for any given type, unless explicitly called by user code." (Section 9.5.3.1.) So unless you have some whacky IL on the loose calling Singleton::.cctor directly (unlikely) your static constructor will run exactly once before the Singleton type is used, only one instance of Singleton will be created, and your Instance property is thread-safe.
Note that if Singleton's constructor accesses the Instance property (even indirectly) then the Instance property will be null. The best you can do is detect when this happens and throw an exception, by checking that instance is non-null in the property accessor. After your static constructor completes the Instance property will be non-null.
As Zoomba's answer points out you will need to make Singleton safe to access from multiple threads, or implement a locking mechanism around using the singleton instance.
Although other answers are mostly correct, there is yet another caveat with static constructors.
As per section II.10.5.3.3 Races and deadlocks of the ECMA-335 Common Language
Infrastructure
Type initialization alone shall not create a deadlock unless some code
called from a type initializer (directly or indirectly) explicitly
invokes blocking operations.
The following code results in a deadlock
using System.Threading;
class MyClass
{
static void Main() { /* Won’t run... the static constructor deadlocks */ }
static MyClass()
{
Thread thread = new Thread(arg => { });
thread.Start();
thread.Join();
}
}
Original author is Igor Ostrovsky, see his post here.
Just to be pedantic, but there is no such thing as a static constructor, but rather static type initializers, here's a small demo of cyclic static constructor dependency which illustrates this point.
Static constructor is guaranteed to be thread safe.
Also, check out the discussion on Singleton at DeveloperZen:
http://web.archive.org/web/20160404231134/http://www.developerzen.com/2007/07/15/whats-wrong-with-this-code-1-discussion/
The static constructor is locked. While the type initializer is running, any other thread which attempts to access the class in such a way that would trigger the type initializer will block.
However, the thread which is running the type initializer can access uninitialized static members. So be sure not to call Monitor.Enter() (lock(){}) or ManualResetEventSlim.Wait() from a type initializer if it is run from a UI thread—those are “interruptible” waits which result in the event loop running, executing arbitrary other parts of your program while your type initializer is still unfinished.
It is preferable for you to use managed blocking rather than unmanaged blocking. WaitHandle.WaitOne, WaitHandle.WaitAny, WaitHandle.WaitAll, Monitor.Enter, Monitor.TryEnter, Thread.Join, GC.WaitForPendingFinalizers, and so on are all responsive to Thread.Interrupt and to Thread.Abort. Also, if your thread is in a single-threaded apartment, all these managed blocking operations will correctly pump messages in your apartment while your thread is blocked: