• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 403
  • Last Modified:

Is this safe with threads?

I'm looking rewriting a code example I found on the intarnet.  Here is a quick run down.

threadMain main() creates a new thread (public STATIC pipeManager), this in turn creates ServerNamedPipe threads.  Each ServerNamedPipe thread calls Form1.PipeManager.WakeUp().  WakeUp in turn calls Mre.Set().  (private ManualResetEvent Mre;)

Question 1: when WakeUp is called the method executes Mre.Set, is this run from the ServerNamedPipe thread or the pipeManger thread?  (I'm 95% sure its SNP thread)
Question 2: The help states the MREs "Any instance members are not guaranteed to be thread safe".  Does the Mre.Set() need to be be within a lock{} ?
Question 3: Or is all this OK as long as the pipeManager is a Static variable?


[Full code can be found here]
http://www.codeproject.com/csharp/DotNetNamedPipesPart1.asp
http://www.codeproject.com/csharp/DotNetNamedPipesPart2.asp
0
ErikPhilips
Asked:
ErikPhilips
  • 2
2 Solutions
 
gregoryyoungCommented:
depending on the operations you are doing on the named pipes you may actually need to look at mutexes to lock between processes (i.e. if you want bi-directional capabilities on the named pipe)

as for your other questions ... you should write a synchronized wrapper for the object if you intend to use it in multiple threads having a static variable actually males it more likely to have thread issues with multiple threads, the reason that most of the static methods throughout the framework are threadsafe is that they are atomic operations, they have no local data storage and operate upon data passed in to them only.
0
 
AvonWyssCommented:
MRE /and the other common waithandles) are threadsafe by design. No need to worry, no lock needed.
0
 
ErikPhilipsAuthor Commented:
Ok but what does the help mean when it says "Any instance members are not guaranteed to be thread safe" for MREs?

(and what about question 1 :)
0
 
AvonWyssCommented:
Well, not guaranteed does not mean that they are not. In fact, I believe that the documentation has not been carefully edited for thread safety; you can read this "Any instance members are not guaranteed to be thread safe" comment at many places.

MRE, ARE, Mutexes, and Monitors are fully thread-safe. This must be so, since they are made to deal with thread concurrency. And if you look behind the scenes (that is, decompile the CLR), you should be able to see that this is true.

Also (concerning question 1), it does not matter which threads set the event. But following your description, it will in fact be your SNP.

Concerning Q3: Note that having a static instance of an object does not make its members static members! Therefore, it does NOT matter if you use static or instance members in regard to thread safety. The thing is that static members usually are state-less (e.g. they don't rely on other members), so that there cannot be a concurrency problem, why they are often thread-safe by design (without having been made thread-safe explicitly).
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now