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


Groups > comp.lang.java.help > #2425

Re: Safety Of Non-Synchronized Collections

Newsgroups comp.lang.java.help
Date 2013-01-09 16:54 -0800
References (5 earlier) <T0lHs.46118$On7.4342@newsfe16.iad> <545e86d1-22b5-42bf-b56f-7c03ac186706@googlegroups.com> <2ZmHs.43434$Sl.37958@newsfe27.iad> <85f704a2-b524-4dc0-abf8-83250d55cc18@googlegroups.com> <28oHs.46827$eK6.10766@newsfe31.iad>
Message-ID <274f6ba0-9d7c-42c7-bddd-76747e7cbd4b@googlegroups.com> (permalink)
Subject Re: Safety Of Non-Synchronized Collections
From Lew <lewbloch@gmail.com>

Show all headers | View raw


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

Back to comp.lang.java.help | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web