Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.help > #2436
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Newsgroups | comp.lang.java.help |
| Subject | Re: Safety Of Non-Synchronized Collections |
| Date | 2013-01-10 17:14 -0500 |
| Organization | A noiseless patient Spider |
| Message-ID | <kcneh0$kmh$1@dont-email.me> (permalink) |
| References | (8 earlier) <lvd2xdw9p0.fsf@saunalahti.fi> <kcmj4t$vkm$1@dont-email.me> <lvbocxdq9t.fsf@saunalahti.fi> <kcmr59$hp6$1@dont-email.me> <lvr4lspvge.fsf@saunalahti.fi> |
On 1/10/2013 4:41 PM, Jukka Lahtinen wrote:
> 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.
Quoth the Javadoc for StringBuffer:
"Whenever an operation occurs involving a source sequence
(such as appending or inserting from a source sequence)
this class synchronizes only on the string buffer performing
the operation [...]"
Therefore, StringBuffer's append() method synchronizes on the
StringBuffer instance being appended to, using the instance's
own monitor. That's the same monitor used by the explicit
`synchronized' in my code example (modified to use StringBuffer
instead of StringBuilder), so there is a mutual exclusion between
the body of append() and the body of the `synchronized' block.
The two executions cannot overlap, interfere, intertwine, entangle,
or cohabit.
(Oddly enough, although StringBuffer's Javadoc says "the
methods are synchronized," only for source-destination methods
does it actually specify what object's lock is used -- and even
that comes as a by-product of saying what object's lock *isn't*
used. Had my example used setCharAt(), say, there could have
been a quibble about whether a mutual exclusion actually exists --
but with append() there's no question.)
--
Eric Sosman
esosman@comcast-dot-net.invalid
Back to comp.lang.java.help | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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