CODEWITHSUNDEEP
.netjsonmultithreadingserializationthread-safety
user334911
user334911

Reputation:

Are different threads on different instances of JavascriptSerializer or JavascriptDeserializer thread safe

I am looking for a definitive answer here.

According to the documentation the public static methods of JavascriptSerializer are thread safe but the non-static methods are not.

Is it guaranteed that for the public non-static methods of this class different instances of running different threads are thread safe (i.e. that there are no private static resources that could violate thread safety)? It is particularly the methods for serializing and deserializing in JavascriptSerializer and JavascriptDeserializer that I am interested in, but would like to know the answer generally.

That is if thread A only runs on instance A and thread B only runs on instance B is there a definitive guarantee of thread safety of the public non-static methods in that scenario?

Upvotes: 5

Views: 1109

Answers (3)

usr
usr

Reputation: 171178

You are not guaranteed thread-safety because only the documentation can guarantee that. But it doesn't.

You cannot test for thread-safety. Threading errors might only turn up under load, or in production.

Also the implementation can change at any time. Install a Windows Update, Service Pack or new version and your code breaks.

As far as I'm concerned, this is a definitive answer - you can't rely on it. Also, I do not see why creating a fresh instance regularly would be a problem even for small amounts of data. The deserialization is far more CPU intensive than instantiating a single object. Creating a (small) object is extremely cheap.

Upvotes: 1

sh1ng
sh1ng

Reputation: 2973

If type contains static private unsafe

state it's like ticking bomb. I guess no one do that.

Upvotes: 1

Tim M.
Tim M.

Reputation: 54359

To recap the question: Can discrete instances of JavaScriptSerializer be used on different threads with a maximum of one thread ever interacting with a particular instance?

I am looking for a definitive answer here.

I can't give you that. However, (as you are probably aware) the thread-safety message in the documentation is extremely generic and appears nearly everywhere (an exception being types for which concurrency is managed).

Anecdotal: I'm not aware of any types which store shared internal state that is not thread-safe. It's tantamount to asking if you can use two different instances of a List or XmlDocument on two different threads; the framework would be quite useless if you could not.

JavaScriptSerializer is meant to be instantiated multiple times on multiple threads as a web server will do (ASP.Net threading is quite complex, but multiple instances of types are certainly created and invoked on different threads). The MVC framework uses JavaScriptSerializer internally, so it's clear that the team intends it to be used in a multi-threaded web environment.

A quick view of the decompiled source shows no shared internal state. As @usr notes, there's no guarantee of consistency in internal implementation. However, it would seem highly unlikely that this would change for the aforementioned reasons.

All that said, the JSON.net library is often considered a superior alternative for JSON (de)serialization for its performance and flexibility.

Upvotes: 5

Related Questions