Shared objects and multithreading issues. Should I care ?

Question

I have a windows service hosting several WCF services. In my windows service I have couple objects with singleton behavior. This objects are accessible thru the WCF services from outside. A call can put a value into the objects and another call can retrieve this value.

Should I care about multithreading issues? I'm not starting any threads by myself. But anyway, should I do any locking when accessesing the singleton objects ? What about methods accessing the objects? Shouldn't they be marked as synchronized ?

EDIT Those objects are not singletons. The objects are created using IoC with singleton behavior.

Answer 1

Yes, I think you should. And something very similar was asked not too long ago.

Object that is needed throughout the application

See this for some explanations

Implementing Singleton in C# , looking at Multithreaded Singleton.

Also Ist way of implementing Singleton Pattern in C#: looking at IIIrd way of implementing Singleton Pattern in C#: Simple Multithreaded Singleton Pattern and IVth way of implementing Singleton Pattern in C#: Multithreaded Singleton Pattern

Answer 2

Every call into your services is a thread of its own. So you are starting threads, quite a lot of them, even.

I am not going to discuss my stance on singletons etc. But, when you have shared mutable data, you have to think about how to protect it from concurrent access. If thread a puts something in there while thread b is looking for something, you might get unpredictable results.

The most obvious solution would be to use a lock for both reading and writing. Check out the docs to ReaderWriterLockSlim which should get you started.