stinger_02in
asked on
C# lock statement block: In a multithreading scenario how bad will be the performance hit?
Hi,
I have an existing code which apart from doing its main job writes to a log file. Now, the application is multithreaded and multiple threads can try to write to the log file. The existing code does not take care of thread synchronization. The basic structure of the code is -
public class A
{
public void writeFullLogFile()
{
//call the function that actually writes to the log file
B.writeToFile();
}
}
public class B
{
public static void writeToFile()
{
//actual file write happens here.
}
}
All I am planning to do get the synchronization is to put a lock statement like below:
public class A
{
private static Object lockMe = new Object();
public void writeFullLogFile()
{
//call the function that actually writes to the log file
lock(lockMe)
{
B.writeToFile();
}
}
}
Now, I want to know how badly does the lock statement affects the performance? How does the performance degrade with an increase in the number of concurrent threads?
Without changing my existing solution much is there a better way to have synchronization?
I have an existing code which apart from doing its main job writes to a log file. Now, the application is multithreaded and multiple threads can try to write to the log file. The existing code does not take care of thread synchronization. The basic structure of the code is -
public class A
{
public void writeFullLogFile()
{
//call the function that actually writes to the log file
B.writeToFile();
}
}
public class B
{
public static void writeToFile()
{
//actual file write happens here.
}
}
All I am planning to do get the synchronization is to put a lock statement like below:
public class A
{
private static Object lockMe = new Object();
public void writeFullLogFile()
{
//call the function that actually writes to the log file
lock(lockMe)
{
B.writeToFile();
}
}
}
Now, I want to know how badly does the lock statement affects the performance? How does the performance degrade with an increase in the number of concurrent threads?
Without changing my existing solution much is there a better way to have synchronization?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Wouldn't you need to lock on the List<> anyway?
nope.. because you will simply just Add() to the static list array.. no need to lock it.
ASKER
As a separate approach can we use TraceSource.Write from System .Diagnostics to write to the log file? As TraceSource is thread safe?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Sorry for that...the method actually is TraceSource.TraceInformati on. And this method is probably not static. So I suppose it is not thread safe either.
The implementation using static List<> seems to be the best.
One final question to get a better understanding: Consider two scenarios -
a. Using locks to write the shared file
b. Using TraceSource.TraceInformati on() to do the same
Do they offer the same performance bottlenecks?
When one thread is writing to the shared file, will the rest of the threads get blocked and wait for the first thread to complete writing? If so, is it same for both scenarios a and b?
TIA,
The implementation using static List<> seems to be the best.
One final question to get a better understanding: Consider two scenarios -
a. Using locks to write the shared file
b. Using TraceSource.TraceInformati
Do they offer the same performance bottlenecks?
When one thread is writing to the shared file, will the rest of the threads get blocked and wait for the first thread to complete writing? If so, is it same for both scenarios a and b?
TIA,
Good question. For the locks writing to a file the answer is yes. But for TraceInformation it doesn't seem to be clearly documented. A quick test would be put a 10 second delay in your listener and see how long TraceInformation takes. If it blocks for 10 seconds then the two approaches would be equivalent. If it doesn't block, then it seems the more attractive option for you. I might guess it will block.
ASKER