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


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

Re: Safety Of Non-Synchronized Collections

From Jukka Lahtinen <jtfjdehf@hotmail.com.invalid>
Newsgroups comp.lang.java.help
Subject Re: Safety Of Non-Synchronized Collections
Organization N/A
References (7 earlier) <2ZmHs.43434$Sl.37958@newsfe27.iad> <lvd2xdw9p0.fsf@saunalahti.fi> <kcmj4t$vkm$1@dont-email.me> <lvbocxdq9t.fsf@saunalahti.fi> <kcmr59$hp6$1@dont-email.me>
Message-ID <lvr4lspvge.fsf@saunalahti.fi> (permalink)
Date 2013-01-10 23:41 +0200

Show all headers | View raw


Eric Sosman <esosman@comcast-dot-net.invalid> writes:
> On 1/10/2013 10:14 AM, Jukka Lahtinen wrote:
>> Eric Sosman <esosman@comcast-dot-net.invalid> writes:
>>> On 1/10/2013 6:37 AM, Jukka Lahtinen wrote:

>>>> Whenever thread safety is needed, you mostly need to synchronize not
>>>> only the single method call to an instance of StringBuffer or some other
>>>> class of the jdk, but also some context around it.

>>>      This is probably not the case, because another thread might
>>> call an (unsynchronized) StringBuilder method while you're in
>>> the middle of your synchronized block:

>> If you use the same instance in many places, potentially in different
>> threads, you should of course synchronize all of them using the same
>> lock.

>>> 	StringBuilder sb = ...;
>>> 	// Thread T1:
>>> 	synchronized(sb) {
>>> 	    if (sb.charAt(sb.length() - 1) == '\n') {
>>> 	        sb.deleteCharAt(sb.length() - 1);
>>> 	    }
>>> 	}

>>> 	// Thread T2:
>>> 	sb.append("Gotcha!");

>> And so, this should be
>> synchronized(sb) {
>>      sb.append("Gotcha?");
>> }

>>> The synchronization in T1's code is no protection against
>>> interference from T2.  If `sb' were changed from a StringBuilder
>>> to a StringBuffer, the race condition would disappear.

>> Like I said, you could be in trouble if T2 makes that call somewhere
>> between the calls to the first sb.length() and sb.deletCharAt in T1 even
>> if sb is a StringBuffer.

>     If T2 makes such a call while T1 is in the synchronized block,
> T2 will stall until T1's synchronized block finishes (or perhaps
> longer).  No race, no trouble.

Only if you add the synchronization also to T2, like I did
above. Without that, nothing will prevent T2 from calling sb.append
between the separate calls from T1 to sb, no matter whether sb is
StringBuffer or StringBuilder.

-- 
Jukka Lahtinen

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