Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.help > #2402 > unrolled thread

Safety Of Non-Synchronized Collections

Back to article view | Back to comp.lang.java.help

Contents

  Safety Of Non-Synchronized Collections Steve <tinker123@gmail.com> - 2013-01-01 15:46 -0500
    Re: Safety Of Non-Synchronized Collections Knute Johnson <nospam@knutejohnson.com> - 2013-01-01 14:18 -0800
      Re: Safety Of Non-Synchronized Collections Lew <lewbloch@gmail.com> - 2013-01-01 15:43 -0800
    Re: Safety Of Non-Synchronized Collections markspace <markspace@nospam.nospam> - 2013-01-01 16:17 -0800
      Re: Safety Of Non-Synchronized Collections Lew <lewbloch@gmail.com> - 2013-01-02 11:12 -0800
        Re: Safety Of Non-Synchronized Collections markspace <markspace@nospam.nospam> - 2013-01-02 12:56 -0800
          Re: Safety Of Non-Synchronized Collections Lew <lewbloch@gmail.com> - 2013-01-02 17:46 -0800
    Re: Safety Of Non-Synchronized Collections Roedy Green <see_website@mindprod.com.invalid> - 2013-01-03 05:59 -0800
      Re: Safety Of Non-Synchronized Collections Lew <lewbloch@gmail.com> - 2013-01-03 15:30 -0800
        Re: Safety Of Non-Synchronized Collections Roedy Green <see_website@mindprod.com.invalid> - 2013-01-09 12:17 -0800
          Re: Safety Of Non-Synchronized Collections Lew <lewbloch@gmail.com> - 2013-01-09 12:56 -0800
            Re: Safety Of Non-Synchronized Collections Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-01-09 13:10 -0800
              Re: Safety Of Non-Synchronized Collections Lew <lewbloch@gmail.com> - 2013-01-09 14:51 -0800
                Re: Safety Of Non-Synchronized Collections Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-01-09 15:22 -0800
                  Re: Safety Of Non-Synchronized Collections Lew <lewbloch@gmail.com> - 2013-01-09 16:26 -0800
                    Re: Safety Of Non-Synchronized Collections Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-01-09 16:42 -0800
                      Re: Safety Of Non-Synchronized Collections Lew <lewbloch@gmail.com> - 2013-01-09 16:54 -0800
                        Re: Safety Of Non-Synchronized Collections Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-01-10 10:30 -0800
                          Re: Safety Of Non-Synchronized Collections Lew <lewbloch@gmail.com> - 2013-01-10 10:58 -0800
                    Re: Safety Of Non-Synchronized Collections markspace <markspace@nospam.nospam> - 2013-01-09 16:50 -0800
                      Re: Safety Of Non-Synchronized Collections Lew <lewbloch@gmail.com> - 2013-01-09 16:59 -0800
                        Re: Safety Of Non-Synchronized Collections markspace <markspace@nospam.nospam> - 2013-01-10 08:18 -0800
                          Re: Safety Of Non-Synchronized Collections Lew <lewbloch@gmail.com> - 2013-01-10 10:49 -0800
                  Re: Safety Of Non-Synchronized Collections Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2013-01-10 13:37 +0200
                    Re: Safety Of Non-Synchronized Collections Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-01-10 09:27 -0500
                      Re: Safety Of Non-Synchronized Collections Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2013-01-10 17:14 +0200
                        Re: Safety Of Non-Synchronized Collections Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-01-10 11:44 -0500
                          Re: Safety Of Non-Synchronized Collections Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2013-01-10 23:41 +0200
                            Re: Safety Of Non-Synchronized Collections Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-01-10 17:14 -0500
                              Re: Safety Of Non-Synchronized Collections Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2013-01-11 09:10 +0200
                                Re: Safety Of Non-Synchronized Collections Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-01-11 08:25 -0500

Page 1 of 2  [1] 2  Next page →

#2402 — Safety Of Non-Synchronized Collections

I was reading a thread about using StringBuilder versus StringBuffer.

The bottom line seemed to be that the two collections were the same 
thing except that a StringBuffer is synchronized, is a thread safe and 
does a little less well in performance as compared to StringBuilder 
which are not those things.

Someone brought up how a similar relationship existed between ArrayList 
and Vector.

Is it a good (SAFE) rule of thumb to NOT use synchronized collections ( 
or anything else ) unless I am consciously creating multiple threads?

In other words, I got the message "Use the new StringBuilder wherever 
possible.", what I want to know is, how can I be sure it is possible?

Am I safe using non-synchronized collections as long as I don't create 
new threads intentionally?

[toc] | [next] | [standalone]

#2403

On 1/1/2013 12:46 PM, Steve wrote:
> I was reading a thread about using StringBuilder versus StringBuffer.
>
> The bottom line seemed to be that the two collections were the same
> thing except that a StringBuffer is synchronized, is a thread safe and
> does a little less well in performance as compared to StringBuilder
> which are not those things.
>
> Someone brought up how a similar relationship existed between ArrayList
> and Vector.
>
> Is it a good (SAFE) rule of thumb to NOT use synchronized collections (
> or anything else ) unless I am consciously creating multiple threads?
>
> In other words, I got the message "Use the new StringBuilder wherever
> possible.", what I want to know is, how can I be sure it is possible?
>
> Am I safe using non-synchronized collections as long as I don't create
> new threads intentionally?

Your question is really too complicated to answer simply.  I suggest 
your buy and read the best book on the subject "Java Concurrency In 
Practice" by Goetz et al.  It is the definitive book at this point.

For a simple rule of thumb however, if you only access an object's 
fields or methods from one thread, no synchronization is necessary. 
That is known as thread constraint and is one way to not have to do any 
external synchronization.

You will find that some folks are a bit rabid about the Vector/ArrayList 
and StringBuffer/Builder thing but in most circumstances you'll never 
notice the difference.

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#2404

Knute Johnson wrote:
> Steve wrote:
>> I was reading a thread about using StringBuilder versus StringBuffer.
>> The bottom line seemed to be that the two collections were the same

They aren't collections.

>> thing except that a StringBuffer is synchronized, is a thread safe and

It has synchronized methods. That doesn't make it thread safe.

>> does a little less well in performance as compared to StringBuilder
>> which are not those things.

StringBuilder is recommended. You pretty much will never need to share it 
between threads.

>> Someone brought up how a similar relationship existed between ArrayList
>> and Vector.

In the limited respect that Vector's methods are synchronized and those of 
ArrayList are not, the situation is similar. In other respects it is quite 
different.

>> Is it a good (SAFE) rule of thumb to NOT use synchronized collections (
>> or anything else ) unless I am consciously creating multiple threads?

What's your opinion?

Rules of thumb are, by definition, limited. You need to know when to apply 
them and when not to. Absent that, no rule of thumb is good or safe.

You spelled "SAFE" in all caps. Why? Does that mean it's more important to 
you than other considerations?

>> In other words, I got the message "Use the new StringBuilder wherever
>> possible.", what I want to know is, how can I be sure it is possible?

Never share it between threads. Then it's always possible.

If you have to share it between threads, don't. Don't use StringBuffer either.

Share Strings between threads. They're (effectively) immutable.

That makes them safe.

So build your String and share the result. Don't share the builder.

>> Am I safe using non-synchronized collections as long as I don't create
>> new threads intentionally?

You are never safe using anything you don't understand.

You aren't even safe using synchronized collections in a multi-threaded 
context. Also, you don't use Vector when you need a synchronized collection,
except when interacting with legacy code that doesn't recognize 'List'.


> Your question is really too complicated to answer simply.  I suggest 

Well, the simple rule of thumb is "Don't use StringBuffer. Don't use Vector."

The better rule (not of thumb) is "Know thine API."

> your buy and read the best book on the subject "Java Concurrency In 
> Practice" by Goetz et al.  It is the definitive book at this point.

+1

> For a simple rule of thumb however, if you only access an object's 
> fields or methods from one thread, no synchronization is necessary. 
> That is known as thread constraint and is one way to not have to do any 
> external synchronization.

Another rule of thumb is declare final references to immutable instances. 

If you don't change the value after you hit a synchronization boundary, you 
don't have to synchronize further.

> You will find that some folks are a bit rabid about the Vector/ArrayList 
> and StringBuffer/Builder thing but in most circumstances you'll never 
> notice the difference.

Sure you will. StringBuilder is not spelled with a "Buffer", and "Vector" 
appears nowhere in the "ArrayList" declaration.

Basically, don't use StringBuffer or Vector at all.

If you are certain that you absolutely must, and you understand all the 
ramifications, you won't need my advice.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#2405

On 1/1/2013 12:46 PM, Steve wrote:
> In other words, I got the message "Use the new StringBuilder wherever
> possible.", what I want to know is, how can I be sure it is possible?

I have to second the suggestion to obtain a good reference on the 
subject and read it.  Java Concurrency in Practice is the only such good 
reference I know, although the Java Language Specification is good too, 
just a bit thick.

I kind of disagree with Lew's rule about final fields and immutability. 
  It's too easy to mess up if you don't what you are doing.  The 
following seems to fit Lew's brief description, but it isn't immutable, 
or thread safe:

public class ImmutableStringBuilder {
   private final StringBuilder sb;

   public ImmutableStringBuilder( StringBuilder sb ) {
     this.sb = sb;
   }
}

So it's hard to catch errors like this if you don't really understand 
Java's memory model.  (Memory model = multi-threading, for all intents 
and purposes.)  Check out the Memory Model section of the JLS, and get 
JCiP.  It's really the only way.

[toc] | [prev] | [next] | [standalone]

#2406

markspace wrote:
> Steve wrote:
>> In other words, I got the message "Use the new StringBuilder wherever
>> possible.", what I want to know is, how can I be sure it is possible?
> 
> I have to second the suggestion to obtain a good reference on the 
> subject and read it.  Java Concurrency in Practice is the only such good 
> reference I know, although the Java Language Specification is good too, 
> just a bit thick.
> 
> 
> 
> I kind of disagree with Lew's rule about final fields and immutability. 

What you show lacks immutability.

>   It's too easy to mess up if you don't what you are doing.  The 

Not if you keep things immutable. That's the defense against not knowing 
what you're doing.

> following seems to fit Lew's brief description, but it isn't immutable, 

Therefore does not seem to fit my definition.

You confuse me.

> or thread safe:

I did say "immutable".

If you don't know what that is, either learn or give up programming.

> public class ImmutableStringBuilder {
>    private final StringBuilder sb;
> 
>    public ImmutableStringBuilder( StringBuilder sb ) {
>      this.sb = sb;
>    }
> }
 
> So it's hard to catch errors like this if you don't really understand 
> Java's memory model.  (Memory model = multi-threading, for all intents 
> and purposes.)  Check out the Memory Model section of the JLS, and get 
> JCiP.  It's really the only way.

I agree, but many of the subtleties of multi-threaded programming in Java are 
avoided by the use of immutable objects. Yes, you do have to understand what 
immutable means. Thank you for illustrating that.

But you don't have to understand absolutely everything about concurrent programming 
to get that much right. Nor do you have to be a master of concurrent programming, 
not that that's really possible, to do any.

I read through JCIP and many of Brian Goetz's excellent articles on IBM Developerworks 
about Java concurrency. The /happens-before/ relationship definitely helps one to reason 
correctly about it. But it didn't make me a master, despite decades of experience in 
concurrent programming. But I'm better than average.

Even with knowledge, it's just so much easier to rely on immutability. Lazy instantiation 
is a false bargain.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#2407

On 1/2/2013 11:12 AM, Lew wrote:

> But you don't have to understand absolutely everything about
> concurrent programming to get that much right. Nor do you have to be
> a master of concurrent programming, not that that's really possible,
> to do any.


Not understand everything, no.  But I do think you have master the basic 
Java language specification in order to be able to reason about when 
your code is safe, and when it's not, for coding in Java.  I hardly know 
everything about concurrency, but I can usually write thread-safe code. 
  It's pretty easy once you understand how.

But I do restrict myself to a subset of Java and concurrency.  Reasoning 
from first principles is hard.  I try to avoid it.  Using basic patterns 
like immutability, safe publication, ad-hoc thread confinement and the 
java.lang.concurrent package will get you a long ways in any concurrency 
project.

But if you haven't at least tried to reason those patterns out and 
understand them in terms of the basic language specification, I don't 
think you could use them successfully.  Not 100% of the time; and 
probably no more than 50%.

[toc] | [prev] | [next] | [standalone]

#2408

markspace wrote:
> Lew wrote:
>> But you don't have to understand absolutely everything about
>> concurrent programming to get that much right. Nor do you have to be
>> a master of concurrent programming, not that that's really possible,
>> to do any.
> 
> Not understand everything, no.  But I do think you have master the basic 
> Java language specification in order to be able to reason about when 

Did I not say essentially that?

> your code is safe, and when it's not, for coding in Java.  I hardly know 
> everything about concurrency, but I can usually write thread-safe code. 

Did I not say that was the pattern?

"But you don't have to understand absolutely everything about concurrent programming ..."

>   It's pretty easy once you understand how.

"The /happens-before/ relationship definitely helps one to reason 
correctly about [concurrency]."

> But I do restrict myself to a subset of Java and concurrency.  Reasoning 
> 
> from first principles is hard.  I try to avoid it.  Using basic patterns 
> 
> like immutability, safe publication, ad-hoc thread confinement and the 

From my post: "Yes, you do have to understand what immutable means."

> java.lang.concurrent package will get you a long ways in any concurrency 
> project.

"Even with knowledge, it's just so much easier to rely on immutability."

> But if you haven't at least tried to reason those patterns out and 
> understand them in terms of the basic language specification, I don't 
> think you could use them successfully.  Not 100% of the time; and 
> probably no more than 50%.

We vehemently agree.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#2409

On Tue, 01 Jan 2013 15:46:37 -0500, Steve <tinker123@gmail.com> wrote,
quoted or indirectly quoted someone who said :

>The bottom line seemed to be that the two collections were the same 
>thing except that a StringBuffer is synchronized, is a thread safe and 
>does a little less well in performance as compared to StringBuilder 
>which are not those things.

Your rules of thumb will work most of the time.  Someone might think
of a pathological case, but I can't offhand. 

I always use StringBuilder in preference to StringBuffer except when I
am writing for very old versions of Java (as in Wassup).  I am also
forced to use it in Regex search/replace which uses the legacy
StringBuffer class.

But actually I nearly always use FastCat which is much more memory
efficient than StringBuilder.  You have to estimate how many pieces
you will join, not their total length. That is much easier.
see http://mindprod.com/products.html#FASTCAT

You almost never share a StringBuilder between threads. It is
invariably referenced by a local variable. So the need for thread safe
code rarely comes up.

I wish there were an optimisation possible in such code. It composes a
char array which it then converts to a String. In theory it should be
possible to create the String from that array which is no longer
needed without making a copy.  The problem is making sure there are no
references to the array.  You build a proto string containing a char
array, copy strings into in, then convert it into a real string. Such
code could prevent an references to the array from being created.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Students who hire or con others to do their homework are as foolish 
as couch potatoes who hire others to go to the gym for them. 

[toc] | [prev] | [next] | [standalone]

#2412

Roedy Green wrote:
>Steve wrote, quoted or indirectly quoted someone who said :
>>The bottom line seemed to be that the two collections were the same 
>>thing except that a StringBuffer is synchronized, is a thread safe and 
>>does a little less well in performance as compared to StringBuilder 
>>which are not those things.
> 
> Your rules of thumb will work most of the time.  Someone might think
> of a pathological case, but I can't offhand. 

Well, there's the fact that StringBuffer is not thread-safe.

> I always use StringBuilder in preference to StringBuffer except when I
> am writing for very old versions of Java (as in Wassup).  I am also

Good policy.

> forced to use it in Regex search/replace which uses the legacy
> StringBuffer class.
> 
> But actually I nearly always use FastCat which is much more memory
> efficient than StringBuilder.  You have to estimate how many pieces
> you will join, not their total length. That is much easier.
> 
> see http://mindprod.com/products.html#FASTCAT
> 
> You almost never share a StringBuilder between threads. It is
> invariably referenced by a local variable. So the need for thread safe
> code rarely comes up.
> 
> I wish there were an optimisation possible in such code. It composes a
> char array which it then converts to a String. In theory it should be
> possible to create the String from that array which is no longer
> needed without making a copy.  The problem is making sure there are no
> references to the array.  You build a proto string containing a char
> array, copy strings into in, then convert it into a real string. Such
> code could prevent an references to the array from being created.

How necessary is this optimization? How much does it hurt performance? 
How much is that affected by HotSpot?

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#2414

On Thu, 3 Jan 2013 15:30:59 -0800 (PST), Lew <lewbloch@gmail.com>
wrote, quoted or indirectly quoted someone who said :

>
>Well, there's the fact that StringBuffer is not thread-safe.

Sun advertised it as such even if it were not perfectly so.  When
StringBuilder was announced in JDK 1.5 Sun had this to say about
StringBuilder

http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/StringBuilder.html
A mutable sequence of characters. This class provides an API
compatible with StringBuffer, but with no guarantee of
synchronization. This class is designed for use as a drop-in
replacement for StringBuffer in places where the string buffer was
being used by a single thread (as is generally the case). Where
possible, it is recommended that this class be used in preference to
StringBuffer as it will be faster under most implementations. 
... 
Instances of StringBuilder are not safe for use by multiple threads.
If such synchronization is required then it is recommended that
StringBuffer be used.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Students who hire or con others to do their homework are as foolish 
as couch potatoes who hire others to go to the gym for them. 

[toc] | [prev] | [next] | [standalone]

#2415

Roedy Green wrote:
> Lew wrote, quoted or indirectly quoted someone who said :
>>Well, there's the fact that StringBuffer is not thread-safe.
> 
> Sun advertised it as such even if it were not perfectly so.  When

Never saw it advertised as such myself.

> StringBuilder was announced in JDK 1.5 Sun had this to say about
> StringBuilder
> 
> http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/StringBuilder.html
> A mutable sequence of characters. This class provides an API
> compatible with StringBuffer, but with no guarantee of
> synchronization. This class is designed for use as a drop-in
> replacement for StringBuffer in places where the string buffer was
> being used by a single thread (as is generally the case). Where
> possible, it is recommended that this class be used in preference to
> StringBuffer as it will be faster under most implementations. 
> ... 
> Instances of StringBuilder are not safe for use by multiple threads.
> If such synchronization is required then it is recommended that
> StringBuffer be used.

Nowhere in the passage you cite does it state that 'StringBuffer' is thread safe.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#2416

On 1/9/13 12:56 PM, Lew wrote:
> Roedy Green wrote:
>> Lew wrote, quoted or indirectly quoted someone who said :
>>> Well, there's the fact that StringBuffer is not thread-safe.
>>
>> Sun advertised it as such even if it were not perfectly so.  When
>
> Never saw it advertised as such myself.
>
>> StringBuilder was announced in JDK 1.5 Sun had this to say about
>> StringBuilder
>>
>> http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/StringBuilder.html
>> A mutable sequence of characters. This class provides an API
>> compatible with StringBuffer, but with no guarantee of
>> synchronization. This class is designed for use as a drop-in
>> replacement for StringBuffer in places where the string buffer was
>> being used by a single thread (as is generally the case). Where
>> possible, it is recommended that this class be used in preference to
>> StringBuffer as it will be faster under most implementations.
>> ...
>> Instances of StringBuilder are not safe for use by multiple threads.
>> If such synchronization is required then it is recommended that
>> StringBuffer be used.
>
> Nowhere in the passage you cite does it state that 'StringBuffer' is thread safe.

Directly in StringBuffer JavaDoc, where you'd expect.

 From <http://docs.oracle.com/javase/7/docs/api/java/lang/StringBuffer.html>

The first two paragraphs:
> A thread-safe, mutable sequence of characters. A string buffer is like a String, but can be modified. At any point in time it contains some particular sequence of characters, but the length and content of the sequence can be changed through certain method calls.
>
> String buffers are safe for use by multiple threads. The methods are synchronized where necessary so that all the operations on any particular instance behave as if they occur in some serial order that is consistent with the order of the method calls made by each of the individual threads involved.

[toc] | [prev] | [next] | [standalone]

#2418

Daniel Pitts wrote:
> Lew wrote:
>> Roedy Green wrote:
>>> Lew wrote, quoted or indirectly quoted someone who said :
>>>> Well, there's the fact that StringBuffer is not thread-safe.
>>>
>>> Sun advertised it as such even if it were not perfectly so.  When
> 
>> Never saw it advertised as such myself.
>... 
> Directly in StringBuffer JavaDoc, where you'd expect.
> 
>  From <http://docs.oracle.com/javase/7/docs/api/java/lang/StringBuffer.html>
> 
> The first two paragraphs:
> 
>> A thread-safe, mutable sequence of characters. A string buffer is like a String, but can be modified. At any point in time it contains some particular sequence of characters, but the length and content of the sequence can be changed through certain method calls.
>>
>> String buffers are safe for use by multiple threads. The methods are synchronized where necessary so that all the operations on any particular instance behave as if they occur in some serial order that is consistent with the order of the method calls made by each of the individual threads involved.

They lied.

'StringBuffer' is no more thread safe than any other class with synchronized methods.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#2420

On 1/9/13 2:51 PM, Lew wrote:
> Daniel Pitts wrote:
>> Lew wrote:
>>> Roedy Green wrote:
>>>> Lew wrote, quoted or indirectly quoted someone who said :
>>>>> Well, there's the fact that StringBuffer is not thread-safe.
>>>>
>>>> Sun advertised it as such even if it were not perfectly so.  When
>>
>>> Never saw it advertised as such myself.
>> ...
>> Directly in StringBuffer JavaDoc, where you'd expect.
>>
>>   From <http://docs.oracle.com/javase/7/docs/api/java/lang/StringBuffer.html>
>>
>> The first two paragraphs:
>>
>>> A thread-safe, mutable sequence of characters. A string buffer is like a String, but can be modified. At any point in time it contains some particular sequence of characters, but the length and content of the sequence can be changed through certain method calls.
>>>
>>> String buffers are safe for use by multiple threads. The methods are synchronized where necessary so that all the operations on any particular instance behave as if they occur in some serial order that is consistent with the order of the method calls made by each of the individual threads involved.
>
> They lied.
>
> 'StringBuffer' is no more thread safe than any other class with synchronized methods.

Which is more safe than other classes without synchronized methods.

They are thread-safe to the point that each method call is atomic. What 
else could you ask for? They didn't lie.

[toc] | [prev] | [next] | [standalone]

#2422

Daniel Pitts wrote:
> Lew wrote:
>> Daniel Pitts wrote:
>>> Lew wrote:
>>>> Roedy Green wrote:
>>>>> Lew wrote, quoted or indirectly quoted someone who said :
>>>>>> Well, there's the fact that StringBuffer is not thread-safe.
> 
>>>>> Sun advertised it as such even if it were not perfectly so.  When
> 
>>>> Never saw it advertised as such myself.
> >> ...
> >> Directly in StringBuffer JavaDoc, where you'd expect.
> >>
> >>   From <http://docs.oracle.com/javase/7/docs/api/java/lang/StringBuffer.html>
> >>
> >> The first two paragraphs:
> 
>>>> A thread-safe, mutable sequence of characters. A string buffer is like a String, but can be modified. At any point in time it contains some particular sequence of characters, but the length and content of the sequence can be changed through certain method calls.
>>>>
>>>> String buffers are safe for use by multiple threads. The methods are synchronized where necessary so that all the operations on any particular instance behave as if they occur in some serial order that is consistent with the order of the method calls made by each of the individual threads involved.
> 
>> They lied.
> 
>> 'StringBuffer' is no more thread safe than any other class with synchronized methods.
> 
> Which is more safe than other classes without synchronized methods.

But safe is binary. "More safe" if less than 100% still is "unsafe".

> They are thread-safe to the point that each method call is atomic. What 
> else could you ask for? They didn't lie.

I could ask for complete thread safety, which synchronized methods do not guarantee.

They did lie.

http://rayfd.me/2007/11/11/when-a-synchronized-class-isnt-threadsafe/

This is elementary concurrency gotcha lore.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#2423

On 1/9/13 4:26 PM, Lew wrote:
> Daniel Pitts wrote:
>> Lew wrote:
>>> Daniel Pitts wrote:
>>>> Lew wrote:
>>>>> Roedy Green wrote:
>>>>>> Lew wrote, quoted or indirectly quoted someone who said :
>>>>>>> Well, there's the fact that StringBuffer is not thread-safe.
>>
>>>>>> Sun advertised it as such even if it were not perfectly so.  When
>>
>>>>> Never saw it advertised as such myself.
>>>> ...
>>>> Directly in StringBuffer JavaDoc, where you'd expect.
>>>>
>>>>    From <http://docs.oracle.com/javase/7/docs/api/java/lang/StringBuffer.html>
>>>>
>>>> The first two paragraphs:
>>
>>>>> A thread-safe, mutable sequence of characters. A string buffer is like a String, but can be modified. At any point in time it contains some particular sequence of characters, but the length and content of the sequence can be changed through certain method calls.
>>>>>
>>>>> String buffers are safe for use by multiple threads. The methods are synchronized where necessary so that all the operations on any particular instance behave as if they occur in some serial order that is consistent with the order of the method calls made by each of the individual threads involved.
>>
>>> They lied.
>>
>>> 'StringBuffer' is no more thread safe than any other class with synchronized methods.
>>
>> Which is more safe than other classes without synchronized methods.
>
> But safe is binary. "More safe" if less than 100% still is "unsafe".
>
>> They are thread-safe to the point that each method call is atomic. What
>> else could you ask for? They didn't lie.
>
> I could ask for complete thread safety, which synchronized methods do not guarantee.
>
> They did lie.
>
> http://rayfd.me/2007/11/11/when-a-synchronized-class-isnt-threadsafe/
>
> This is elementary concurrency gotcha lore.
>
Wow, you mean if I don't use an API as intended, it doesn't work as 
intended?  Sarcasm aside, a Thread-Safe class means the methods on it 
can be called concurrently, and the operations are performed as 
described.  If you don't have any consideration for thread safety in 
your class, then data could get mangled and unexpected/undefined 
behavior could happen.

Now, operations may or may not be thread-safe, externally to whether or 
not they operate on a thread-safe class. Any operation which must be 
atomic with regards to the state of that class needs to either be a CAS 
style operation (update the state if the state hasn't already been 
updated), a single operation synchronized against the common lock 
object, or externally managed.

[toc] | [prev] | [next] | [standalone]

#2425

Daniel Pitts wrote:
> Lew wrote:
>> Daniel Pitts wrote:
>>> Lew wrote:
>>>> Daniel Pitts wrote:
>>>>> Lew wrote:
>>>>>> Roedy Green wrote:
>>>>>>> Lew wrote, quoted or indirectly quoted someone who said :
>>>>>>>> Well, there's the fact that StringBuffer is not thread-safe.
> 
>>>>>>> Sun advertised it as such even if it were not perfectly so.  When
> 
>>>>>> Never saw it advertised as such myself.
>>>>> ...
>>>>> Directly in StringBuffer JavaDoc, where you'd expect.
> 
>>>>>    From <http://docs.oracle.com/javase/7/docs/api/java/lang/StringBuffer.html>
> 
>>>>> The first two paragraphs:
> 
>>>>>> A thread-safe, mutable sequence of characters. A string buffer is like a String, but can be modified. At any point in time it contains some particular sequence of characters, but the length and content of the sequence can be changed through certain method calls.
>>>>>>
>>>>>> String buffers are safe for use by multiple threads. The methods are synchronized where necessary so that all the operations on any particular instance behave as if they occur in some serial order that is consistent with the order of the method calls made by each of the individual threads involved.
> 
>>>> They lied.
> 
>>>> 'StringBuffer' is no more thread safe than any other class with synchronized methods.
> 
>>> Which is more safe than other classes without synchronized methods.
> 
>> But safe is binary. "More safe" if less than 100% still is "unsafe".
> 
>>> They are thread-safe to the point that each method call is atomic. What
>>> else could you ask for? They didn't lie.
>>
>> I could ask for complete thread safety, which synchronized methods do not guarantee.
> 
>> They did lie.
> 
>> http://rayfd.me/2007/11/11/when-a-synchronized-class-isnt-threadsafe/
> 
>> This is elementary concurrency gotcha lore.
> 
> Wow, you mean if I don't use an API as intended, it doesn't work as 
> intended?  Sarcasm aside, a Thread-Safe class means the methods on it 
> can be called concurrently, and the operations are performed as 

No, that's not what it means.

http://www.ibm.com/developerworks/java/library/j-jtp09263/index.html

Which, by the way, corrects my misstatement. Turns out there are degrees of safety.

I'm going to stick with Brian Goetz's definition over yours.

> described.  If you don't have any consideration for thread safety in 
> your class, then data could get mangled and unexpected/undefined 
> behavior could happen.

Yes, which is why it's important to know that synchronized methods do not 
make a class thread safe, only those individual methods.

> Now, operations may or may not be thread-safe, externally to whether or 
> not they operate on a thread-safe class. Any operation which must be 

By your "No True Scotsman" definition of thread safe.

> atomic with regards to the state of that class needs to either be a CAS 
> style operation (update the state if the state hasn't already been 
> updated), a single operation synchronized against the common lock 
> object, or externally managed.

Or, like the java.util.concurrent classes, handle that stuff for you.

Which would make it thread safe.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#2432

On 1/9/13 4:54 PM, Lew wrote:
> Daniel Pitts wrote:
>> Lew wrote:
>>> Daniel Pitts wrote:
>>>> Lew wrote:
>>>>> Daniel Pitts wrote:
>>>>>> Lew wrote:
>>>>>>> Roedy Green wrote:
>>>>>>>> Lew wrote, quoted or indirectly quoted someone who said :
>>>>>>>>> Well, there's the fact that StringBuffer is not thread-safe.
>>
>>>>>>>> Sun advertised it as such even if it were not perfectly so.  When
>>
>>>>>>> Never saw it advertised as such myself.
>>>>>> ...
>>>>>> Directly in StringBuffer JavaDoc, where you'd expect.
>>
>>>>>>     From <http://docs.oracle.com/javase/7/docs/api/java/lang/StringBuffer.html>
>>
>>>>>> The first two paragraphs:
>>
>>>>>>> A thread-safe, mutable sequence of characters. A string buffer is like a String, but can be modified. At any point in time it contains some particular sequence of characters, but the length and content of the sequence can be changed through certain method calls.
>>>>>>>
>>>>>>> String buffers are safe for use by multiple threads. The methods are synchronized where necessary so that all the operations on any particular instance behave as if they occur in some serial order that is consistent with the order of the method calls made by each of the individual threads involved.
>>
>>>>> They lied.
>>
>>>>> 'StringBuffer' is no more thread safe than any other class with synchronized methods.
>>
>>>> Which is more safe than other classes without synchronized methods.
>>
>>> But safe is binary. "More safe" if less than 100% still is "unsafe".
>>
>>>> They are thread-safe to the point that each method call is atomic. What
>>>> else could you ask for? They didn't lie.
>>>
>>> I could ask for complete thread safety, which synchronized methods do not guarantee.
>>
>>> They did lie.
>>
>>> http://rayfd.me/2007/11/11/when-a-synchronized-class-isnt-threadsafe/
>>
>>> This is elementary concurrency gotcha lore.
>>
>> Wow, you mean if I don't use an API as intended, it doesn't work as
>> intended?  Sarcasm aside, a Thread-Safe class means the methods on it
>> can be called concurrently, and the operations are performed as
>
> No, that's not what it means.
>
> http://www.ibm.com/developerworks/java/library/j-jtp09263/index.html
>
> Which, by the way, corrects my misstatement. Turns out there are degrees of safety.
>
> I'm going to stick with Brian Goetz's definition over yours.
>
>> described.  If you don't have any consideration for thread safety in
>> your class, then data could get mangled and unexpected/undefined
>> behavior could happen.
>
> Yes, which is why it's important to know that synchronized methods do not
> make a class thread safe, only those individual methods.
>
>> Now, operations may or may not be thread-safe, externally to whether or
>> not they operate on a thread-safe class. Any operation which must be
>
> By your "No True Scotsman" definition of thread safe.
>
>> atomic with regards to the state of that class needs to either be a CAS
>> style operation (update the state if the state hasn't already been
>> updated), a single operation synchronized against the common lock
>> object, or externally managed.
>
> Or, like the java.util.concurrent classes, handle that stuff for you.
>
> Which would make it thread safe.
>
Those provide a way to do the operations I talked about, but even using 
those classes, you can write code that isn't thread safe...

I think it comes down to the fact that only specific operations can be 
deemed thread-safe or not thread-safe.  Combining otherwise thread-safe 
operations result in a new operation which may also be either 
thread-safe or not thread-safe.  Therefor just because you only ever 
access "thread-safe" methods, doesn't mean your code is thread safe.

[toc] | [prev] | [next] | [standalone]

#2434

Daniel Pitts wrote:
> I think it comes down to the fact that only specific operations can be 
> deemed thread-safe or not thread-safe.  Combining otherwise thread-safe 
> operations result in a new operation which may also be either 
> thread-safe or not thread-safe.  Therefor just because you only ever 
> access "thread-safe" methods, doesn't mean your code is thread safe.

Makes sense.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#2424

On 1/9/2013 4:26 PM, Lew wrote:
>
> http://rayfd.me/2007/11/11/when-a-synchronized-class-isnt-threadsafe/
>
> This is elementary concurrency gotcha lore.
>

Note this sentence from the article: "Changing the synchronized List to 
Vector doesn't help either."

Vector is thread safe.  Objects wrapped by Collections.synchronized() 
are thread safe.  This does not guarantee that every use of those 
classes is safe, or correct.

Their example is of a single collection which is accessed by multiple 
threads.  As they show their example produces errors.  This is an issue 
of atomicity, not thread safety.  The single collection is still 
perfectly safe, in spite of the errors.  There are no data races. 
However, the program produces errors because it is poorly designed.  It 
requires atomicity, and synchronized methods don't provide that across 
multiple method calls.

So the problem is really one of quibbling over terminology.  Thread 
safety and atomicity both fall under the more general heading of 
concurrency and concurrent programming.  Thread safety and atomicity are 
not the same thing.  They overlap a bit, but not much, so it's best to 
actually understand what is being discussed.  In Java, thread safe means 
an absence of data races, but that's all.  It says nothing about 
atomicity, or the correctness of any given program.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.help

csiph-web