For the question that I have probably I need more convincing answer to implement in my solution. I am not sure whether my understanding is correct. Following are the implementation details:
In a class, in the main method, where the class object C is created to call an instance method that takes integer as a parameter:
public <AnyClass> MyMethod(int classVar)
{
return new <AnyClass>(classVar);
// Can have more implementation, using the parameter passed
}
In the main, I want this method to be called on the multiple threads, using the same class object, the parameter would be the value supplied by for loop that starts the threads to execute. Now in memory we are executing same method, does this needs any kind of locking. In my view No, I have tested, but I am not sure in theory why, wouldn't different threads mess up with each other's parameter value, in my implementation it doesn't seems the case.
Only thing I cannot guarantee, is which thread access and returns first as that would not be in the order, but if I do not care about it, is this implementation correct.
Please note, this is an attempt to describe the issue in a stand alone manner, I have similar implementation as part of a complex project.
Any suggestions / pointers would be great. Please let me know if you need a clarification.
No, you don't have to lock anything here:
Code is read-only, so two threads executing the same code have no problem.
Each thread has its own stack, so threads can't mess up each other's stack-based variables.
However, when two threads may see the same object, and at least one modifies it, you may need to lock that object.
you are absolutely correct!
no sort of locking is required. locking is required when the code within the method accesses something other than what came through the parameters. if your code accesses instance variables or singleton objects then you might need locking. i say might because if your code accesses these external data in read-only manner then you wont need locking.
fundamentally, you need locking if and only if two parallel threads access and mutate (change) any data shared between them.
as for the method-arguments, they are personal to each thread. two threads can invoke same method, at the same time with different arguments. both threads will work fine. as long as the code is confined to working with only the data it got in the arguments.
in the sample code, you did not access any shared-data, hence locking is not required. hope you are convinced enough.
You are not accessing any shared resources in your method as it is written (assuming the constructor to AnyClass also doesn't)
In addition, the parameter (int) that you are passing in, is passed by value, so even if your method did change it, it would only change a local copy of it on the stack of the method being called.
So from what you've shown, there is no need to do any locking. The sort of thing where you would need to lock might be if you were passing in the same instance of an object into your method and then doing something to change the state of that object, in which case you would need to synchronize access to the state of the object.
Related
I wonder how to guarantee thread-safety on pipes during async operations.
For example this code is being executed by a thread (the stream has been created properly before):
pipeClientStream.ConnectAsync(cancel).Wait();
Meanwhile another thread wants to know if the pipe is (already) connected
bool isConnected = pipeClientStream.IsConnected;
I didn't find a notice about thread-safety in the microsoft docs, but I guess if it was thread-safe there would be a hint. I also dived into reference source of the Pipe.cs and PipeStream.cs to look for locks but there where none to be found.
So in the end the only "safe" way would be to create a "locked" boolean value set by the thread which is working with the pipe and encapsulate the pipe.
What do you think is proper way of dealing with such scenarios?
the proper way to deal with most non-threadsafe object is to lock it:
lock(pipeClientStream){
return pipeClientStream.IsConnected;
}
Locking a shared resource like this is fine, but it it also common to use a separate object to control access to some resource. If you are using actual asynchronous code you might need some other solution.
do not try to create your own "lock" by using any kind of shared boolean. There is a huge risk you will get something wrong and end up with non threadsafe code.
There are also named mutexes if you need synchronization between processes, but that is not needed if you keep to a single process.
A friend asked me which would be better ThreadStatic or ThreadLocal. Checking the doc I told him ThreadLocal looks more convenient, is available since .NET 4.0, but I don't understand why use any of them over creating object instance for a thread. Their purpose is to store "thread-local-data", so you can call methods less clumsily and avoid locking in some instances. When I wanted such thread-local-data I always was creating something like:
class ThreadHandler
{
SomeClass A;
public ThreadHandler(SomeClass A)
{
this.A = A;
}
public void Worker()
{
}
}
If I want just fire and forget thread it would be new Thread(new ThreadHandler(new SomeClass()).TheWorkerMethod).Start(), if I want to track threads it can be added to collection, if I want to track data ThreadHandler can be added to collection, if I want to handle both I can make Thread property for ThreadHandler and put ThreadHandler to collection, I want threadpool it's QueueUserWorkItem instead of new Thread(). It's short and simple if scope is simple, but easily extensible if scope gets wider.
When I'm trying to google why use ThreadLocal over an object instance all my searches end up with explanation how ThreadLocal is much greater than ThreadStatic, which in my eyes look like people explaining that they had this clumsy screwdriver, but now toolbox has heavy monkey-wrench which is much more convenient for hammering nails. Whilst toolbox had a hammer to begin with.
I understand I'm missing something, because if ThreadStatic/ThreadLocal had no advantage they just wouldn't exist. Can somebody please point out at least one significant advantage of ThreadLocal over creating an object instance for a thread?
UPD: Looks like a double of this, I think when I was googling "java" keyword was throwing me off. So there's at least one advantage - ThreadLocal is more natural to use with Task Parallel Library.
I don't get advantage of ThreadLocal over creating an instance of object for a thread.
You're right, when you have control over the threads being created, and how they're used, it's very handy to just wrap the whole thread in a helper class, and have it get 'thread local' data from there.
The problem is that, especially in institutionally large projects, you don't always have this kind of control. You may start up a thread, and call some code, and that one thread may wind its way through calls in millions of lines of code scattered between 10 projects owned by 3 internal teams and one external contractor team. Good luck plumbing some of those parameters everywhere.
Thread-local storage lets those guys interact without requiring that they have explicit references to the object that represents that thread's context.
A related problem I had was associating data to some thread and every child thread created by that thread (since my large projects create their own threads, and so thread-local doesn't work anymore), see this question I had: Is there any programmable data that is automatically inherited by children Thread objects?
At the end of the day, it's often lazy programming, but sometimes you find situations where you just need it.
ThreadLocal<T> works like a Dictionary<Thread, T>. The problem with a dictionary is that instances belonging to killed or dead threads stay around forever - they don't get garbage collected, because they are referenced by the dictionary. Using ThreadLocal will ensure that, when a thread dies, the instances referenced by that thread are eligible for GC.
Plus, it's a much nicer interface than having to manually deal with a Dictionary<Thread, T>. It Just Works.
ThreadLocal has 2 benefits over ThreadStatic attribute approach, you can avoid to define class-field and it has built in lazy loading feature. your manual collection approach requires locking mechanism, if you look ThreadLocal's source code, you see its optimized to this specific case.
ThreadLocal can get benfits when T type object new and gc frequenctly. And it's thread safe.
I have a component registered in Castle Windsor as a singleton. This object is being used in many other places within my application which is multithreaded.
Is it possible that the two objects will invoke the same method from that singleton at the same time or 'calling it' will be blocked until the previous object will get result?
Thanks
You can call a Singleton object method from different threads at the same time and they would not be blocked if there is no locking/ synchronization code. The threads would not wait for others to process the result and would execute the method as they would execute methods on separate objects.
This is due to the fact that each thread has a separate stack and have different sets of local variables. The rest of the method just describes the process as to what needs to be done with the data which is held the variables/fields.
What you might want to take care of is if the methods on the Singleton object access any static methods or fields/variables. In that case you might need to work on synchronization part of it. You would need to ensure multi-threaded access to shared resources for the execution of the method to be reliable.
To be able to synchronize, you might need to use lock statement or other forms of thread synchronization techniques.
You might want to refer to this article from Wikipedia which provides information on C# thread local storage as well.
You can call the same method or different methods on one object simultaneously from different threads. In the specific methods you'll need to know when sensitive variables are being accessed (mostly when member-variables are changing their values) and will need to implement locking on your own, in order to solve lost updates and other anomalies.
You can lock a part of a code with the lock-statement and here an article on how Thread-Synchronization works in .Net.
The normal version of Singleton may not be thread safe, you could see different implementation of thread safe singleton here.
http://tutorials.csharp-online.net/Singleton_design_pattern:_Thread-safe_Singleton
In many MSDN documents, this is written under the Thread Safety heading;
"Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe."
for example; here
can someone explain it please in a rather simple way?
Thank you :)
Eric Lippert has an excellent blog post about this. Basically it's somewhat meaningless on its own.
Personally I don't trust MSDN too much on this front, when I see that boiler-plate. It doesn't always mean what it says. For example, it says the same thing about Encoding - despite the fact that we all use encodings from multiple threads all over the place.
Unless I have any reason to believe otherwise (which I do with Encoding) I assume that I can call any static member from any thread with no corruption of global state. If I want to use instance members of the same object from different threads, I assume that's okay if I ensure - via locking - that only one thread will use the object at a time. (That's not always the case, of course. Some objects have thread affinity and actively dislike being used from multiple threads, even with locking in place. UI controls are the obvious example.)
Of course, it becomes tricky if objects are being shared unobviously - if I have two objects which each share a reference to a third, then I may end up using the first two objects independently from different threads, with all the proper locking - but still end up corrupting the third object.
If a type does advertise itself to be thread safe, I'd hope that it would give some details about it. It's easy if it's immutable - you can just use instances however you like without worrying about them. It's partially or wholly "thread-safe" types which are mutable where the details matter greatly.
You may access any public static member of that class from multiple threads at the same time, and not disrupt the state of the class. If multiple threads attempt to access the object using instance methods (those methods not marked "static") at the same time, the object may become corrupted.
A class is "thread-safe" if attempts to access the same instance of the class from multiple threads at the same time does not cause problems.
An object being "thread safe" means that if two threads are using it at (or very near, on single-CPU systems) the exact same time, there's no chance of it being corrupted by said access. That's usually achieved by acquiring and releasing locks, which can cause bottlenecks, so "thread safe" can also mean "slow" if it's done when it doesn't need to be.
Public static members are pretty much expected to be shared between threads (Note, VB even calls it "Shared"), so public statics are generally made in such a way that they can be used safely.
Instance members aren't usually thread-safe, because in the general case it'd slow things down. If you have an object you want to share between threads, therefore, you'll need to do your own synchronization/locking.
To understand this, consider the following example.
In MSDN description of .net class HashSet, there is a part that says about the thread safety. In the case of HashSet Class, MSDN says “Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.”
Of cause we all know the concept of race conditions and deadlocks, but what does Microsoft wants to say in simple English?
If two threads add two values to an “instance” of a HashSet there are some situation where we can get its count as one. Of cause in this situation the HashSet object is corrupted since we now have two objects in the HashSet, yet its count shows only one. However, public static version of the HashSet will never face such a corruption even if two threads concurrently add values.
I have a web app that currently uses the current HttpContext to store a LINQ Data Context. The context is persisted for the current request, on a per user basis, per Rick Strahl's blog:
string ocKey = "ocm_" + HttpContext.Current.GetHashCode().ToString("x")
Thread.CurrentContext.ContextID.ToString();
if (!HttpContext.Current.Items.Contains(ocKey))
{
// Get new Data Context and store it in the HTTP Context
}
However, I have some scripts that execute from the global.asax file, that don't have an HttpContext. The HttpContext.Current is NULL, because the server is the one making the "request".
Is there an equivalent object that I can use to store the Data Context? So I don't have to worry about re-creating it, and attaching/detaching objects? I only want to persist the context for the lifetime of my processes.
UPDATED:
I am currently trying to use a static variable in my DAL helper class. on the first call to one of the methods in the class the DataContext is instantiated, and stored in the static variable. At the end of my process, I call another method that calls Dispose on the DataContext, and sets the static variable to NULL.
Can you not just use a static variable specifically for those scripts? That will have the same life-time as the AppDomain. You should probably think carefully about any concurrency concerns, but it sounds like the simplest way to keep a value around.
(I've just checked, and although one instance of HttpApplication can be used to service multiple requests, each one only serves one request at a time - which suggests that multiple instances are created for concurrent request processing. I haven't validated this, but it does sound like it wouldn't be safe to keep it in an instance variable.)
EDIT: Josh's answer suggests that you want this to be per-thread. That sounds slightly odd to me, as unless you've got a lot of these events occurring, you're quite likely to only ever see them execute on different threads, making the whole sharing business pointless. If you really do want that sort of thing, I'd suggest just using an instance variable in the HttpApplication-derived class - for exactly the reason described in the paragraph above :)
Why not use the current HttpContext? The scripts in your global.asax file are all the result of a request coming into the server, so there should be a context associated with that request which you can grab.
I don't understand the need for generating the key based on the hashcode or the thread. There is going to be a separate instance of HttpContext for each request that comes in, and that instance is going to be specific to the thread that is processing the request. Because of that, the key is pretty much worthless when it's based on the instance of HttpContext and the thread.
Also, how do you dispose of the DataContext when you are done? It implements IDisposable for a reason, so I would recommend against a shared instance like this.
UPDATE
In the comments, it indicates that there is a timer that is running that is executing the scripts. Instead of the timer, I would recommend setting up a Scheduled Task which will call a webservice or predetermined page on the site which will perform the task. Then you will always have an HttpContext to work with.
HttpContext.Current is a static method and should be available from anywhere as long as the code is executing within the context of a request.
In your case your not executing within the context of a request, You could look at using Application.Cache but I would caution against holding a DataContext open. I am not very famillar with linq to entities, so I could be wrong, but generally caching data base related items such as connections is bad.
I would also recommend that you consider moving the logic out of your global.asax and to a windows service. This would let you have more control over these tasks, for example you can shut them down seperatley of the web site.
Edit
As JS points out you could use a static variable. You could also define an instance variable marked with ThreadLocal attribute. This will give each thread its own copy of the variable, and can eliminate contention. Since you want each thread to have its own copy anyways.
Is there a reason why these need to be handled the same way as the other DataContexts? It seems to me that if the context is only needed inside the event handling routine, you shouldn't need to keep it around. Especially if it is in Application_Start (as per your comment), I wouldn't bother caching it anywhere -- just use it locally and pass it to the other methods as needed.
Set the DataContext as the state parameter when creating the timer. Based on the info you posted on the comments, it seems to me that your DataContext is more related to the timers than anything else.
Also avoid using the same DataContext for different timers, because you would end up with mixed modifications from the different timers. Also make sure your same timer logic isn't run twice, since it would cause the same i.e. too short period with no control.