aspose file tools*
The moose likes Threads and Synchronization and the fly likes Is this class thread safe Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Is this class thread safe" Watch "Is this class thread safe" New topic
Author

Is this class thread safe

Kalyan Anand
Ranch Hand

Joined: Feb 07, 2007
Posts: 194


If I call the manipulate method by passing same instance of StringBuilder to multiple threads then it is possible that the result is unexpected so should I call this class as Thread-Safe ?
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4181
    
  21

Originally posted by Santhosh Jali:


If I call the manipulate method by passing same instance of StringBuilder to multiple threads then it is possible that the result is unexpected so should I call this class as Thread-Safe ?


Didn't you just answer your own question? Any code that can generate unexpected behavior because of interaction between multiple threads should not be called Thread-Safe.

The best way to make this Thread-Safe would be to pass in a String, convert to StringBuilder to do your work, manipulate the StringBuilder, then return a String results:


Steve
Kalyan Anand
Ranch Hand

Joined: Feb 07, 2007
Posts: 194
All this thought came because of this - This class is termed as an Immutable class and by definition any Immutable class is thread-safe.

so my question is still open
Ulf Dittmer
Rancher

Joined: Mar 22, 2005
Posts: 42952
    
  73
This class is termed as an Immutable class and by definition any Immutable class is thread-safe.

The class has no state at all, so calling it immutable doesn't make much sense. But more importantly, just because the state of a class isn't mutable does NOT imply that it's thread-safe. It may call other classes that do something that's not thread-safe, and that's what's happening here.
Kalyan Anand
Ranch Hand

Joined: Feb 07, 2007
Posts: 194
Originally posted by Ulf Dittmer:

The class has no state at all, so calling it immutable doesn't make much sense. But more importantly, just because the state of a class isn't mutable does NOT imply that it's thread-safe. It may call other classes that do something that's not thread-safe, and that's what's happening here.


You also seem to say that this class is thread-unsafe.

Going by definition in Java Concurrency in Practice by Brian Goetz and Josh Bloch - 1. "Stateless objects are always thread-safe." and "Immutable objects are always thread-safe."
[ October 04, 2008: Message edited by: Santhosh Jali ]
Ulf Dittmer
Rancher

Joined: Mar 22, 2005
Posts: 42952
    
  73
Maybe there's some context to that quote that's missing. The "sb" object in the example is mutable, so it's not safe to share it between threads. It doesn't matter which class does the mutating.
[ October 04, 2008: Message edited by: Ulf Dittmer ]
Kalyan Anand
Ranch Hand

Joined: Feb 07, 2007
Posts: 194
Maybe there's some context to that quote that's missing.

No. These statements specified as a note in a special boxes and they are generic statements.

The "sb" object in the example is mutable, so it's not safe to share it between threads. It doesn't matter which class does the mutating.

Yes sb is muatble but going by the class Test - it doesn't carry any state information with it so Test should be thread-safe.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
I would actually say that that class is thread-safe, but can be used in an un-thread-safe manner.

There is nothing unexpected about the behavior of that class. That doesn't mean, of course, that it can't be used in a system that behaves unexpectedly. And even the definition of "unexpected" could change between systems.

Basically, what we are talking about here is that the system *might* be indeterministic. And even that could be ok - for example, if this was for logging purposes, we probably don't care whether "Hello" will appear at line two or line five of the log file. So even that system could be called thread-safe. It only becomes thread-unsafe when we actually *do* care about it *and* we don't write the system in a way that ensures what we care about.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Ulf Dittmer
Rancher

Joined: Mar 22, 2005
Posts: 42952
    
  73
I would actually say that that class is thread-safe, but can be used in an un-thread-safe manner.

That's a good way of putting it. I suppose one might argue about the difference between a class having mutable state -which this one does not- and a method in the class having mutable state - which this one does.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 19087
    
  40

This is a really really blurry line here. Is a class that can be used in a thread unsafe manner really thread safe?

The term thread safe does seem to focus on whether you can corrupt the data in the class, but users of the class won't seem to make this distinction. Either the class works or it doesn't.

Regardless, I can go either way with this debate.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4181
    
  21

I would also argue that this method makes the class not immutable.

In an immutable object you should be able to call any given method, give it the same inputs, and expect the same, predictable output. With your method not being thread safe, you could pass a StringBuffer with the same data into it and get different and unpredictable results.

So the class may have no changing state which is a requirement for immutable objects, but the method return different results with the same input so the class is not actually immutable.

I think this goes beyond the normal definition and list of requirements for immutable classes, but is mandatory if the statement "Immutable objects are always thread-safe." is to be true.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3019
    
  10
I don' t know - it seems to me as though "Immutable objects are always thread-safe" applies to the immutable object itself, not to other obviously-mutable objects passed in externally that are available to other threads. The only way that this class presents a problem is if the programmer is already sharing the StringBuilder between different threads. I.e. the programmer is already using the StringBuilder in an unsafe manner. The immutable Test class is thread-safe as far as it itself is concerned, but it doesn't automatically confer thread-safety on any other class it comes in contact with.

[Ulf]: The class has no state at all, so calling it immutable doesn't make much sense.

I would argue that an immutable objects are inherently stateless, so you comment doesn't really make sense to me, either. But we're just arguing trivial semantics over a corner case here. The original post could easily have been about a more conventional immutable object, i.e. one with at least one data field:

The basic issue remains: it's an immutable object that is using another object in a way that's not necessarily thread-safe. So if a programmer is already using StringBuilder in an unsafe manner, then the thread-safety of Test will not extend to StringBuilder. Generally, calling a class "thread-safe" refers only to whether that class' own data is safe.

[Ilja]: I would actually say that that class is thread-safe, but can be used in an un-thread-safe manner.

Yup, I would too. This is nothing new in itself - people have been writing unsafe code with vector for years, for example. Calling a class "thread-safe" can often be misleading in that respect - it may still be possible to use a class in an unsafe manner.
[ October 05, 2008: Message edited by: Mike Simmons ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Henry Wong:
Is a class that can be used in a thread unsafe manner really thread safe?


Can you give an example for a class that cannot possibly be used in a thread unsafe manner, ever?
Srikanth Basa
Ranch Hand

Joined: Jun 06, 2005
Posts: 241
Good to see authors, bartenders presenting their views! Here goes mine.

All this discussion appears to boll down to the definition of thread-safety of a class and the conditions taken into consideration in terming it thread-safe.

We term a Vector as thread-safe. But technically, when we perform compound operations on a vector we cannot say that compounded behavior is thread-safe.


Based on my understanding, the following conditions are taken into consideration when we discuss thread-safety of a particular class which satisfies either immutability or synchronization conditions.

1. Don't consider Compound Operations - Based on the conventional knowledge, the vector example (above) proves that a thread-safe class can be thread-unsafe when we perform compound operations on it so when we say a class is thread-safe we shouldn't consider the compound operations.

2. No External Operations in consideration - Many of the thread-safe classes accept array objects in method calls, without using the array in the state information (similar to the one posted by Santhosh). Thus, we don't involve any external operations that tweak the passed objects.
 
 
subject: Is this class thread safe