Is using a Structure safe for Multithreading in c#

Question

I have a Class ReceiveFaxPrintHelper in c# that i implemented as Sealed. I have also implemented this as Singleton. I have a method PrintStoredFaxes defined in this class, which i protect using a lock.

The question i have is if i change ReceiveFaxPrintHelper from class to struct, does this affect my threading? Ndepend suggests me to change this to a structure instead of class.

public sealed class ReceiveFaxPrintHelper
{
    private static AutoResetEvent mJobCompleted = new AutoResetEvent(false);
    private bool mPrintStoredFaxesInProgress = false;
    private object mLockPrint = new object();
    private const string mClassName = "ReceiveFaxPrintHelper";

   /// <summary>
    /// Function that prints the Stored Faxes
    /// </summary>
    /// <param name="o">completing the delegate message signature</param>
    public void PrintStoredFaxes(object o)
    {
        lock (mLockPrint)
        {

I use this like this:

ThreadPool.QueueUserWorkItem(new WaitCallback(ReceiveFaxPrintHelper.Instance.PrintStoredFaxes));

Do you know the difference between a structure and a class? Because based on this question, it does not appear like you do, you might want to do some research on the matter. If you want a single instance of your object you should be using a class not a structure. — Security Hound, Jun 25 '12 at 11:40
Accept at least 80% of your questions for people to start answering you. — AgentFire, Jun 25 '12 at 11:43

score 1 · Accepted Answer · answered Jun 25 '12 at 11:55

NDepend is just misleading you here. Singletons should not be structs.

However, there is no risk of such a mistake specifically breaking locking. mLockPrint is not a struct and so copying of a struct it is contained in will not result in its duplication. You could also make mLockPrint static if singleton behavior was intended for the lock but not for the whole structure.

Furthermore, as long as you use the lock syntax, you are relatively safe against accidentally locking a struct; that would just not compile. The Monitor.Enter syntax is trickier, as it does compile which then results in silent disappearance of locking (more accurately, useless locking of boxed copies).

score 1 · Answer 2 · answered Jun 25 '12 at 11:55

1

It won't break your multithreading... but you should look at the actual differences in more detail:

http://msdn.microsoft.com/en-us/library/ms173109

answered Jun 25 '12 at 11:55

Vok

457
5
19

Is using a Structure safe for Multithreading in c#

2 Answers2