Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.help > #2429
| From | Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> |
|---|---|
| Newsgroups | comp.lang.java.help |
| Subject | Re: Safety Of Non-Synchronized Collections |
| Organization | N/A |
| References | (5 earlier) <T0lHs.46118$On7.4342@newsfe16.iad> <545e86d1-22b5-42bf-b56f-7c03ac186706@googlegroups.com> <2ZmHs.43434$Sl.37958@newsfe27.iad> <lvd2xdw9p0.fsf@saunalahti.fi> <kcmj4t$vkm$1@dont-email.me> |
| Message-ID | <lvbocxdq9t.fsf@saunalahti.fi> (permalink) |
| Date | 2013-01-10 17:14 +0200 |
Eric Sosman <esosman@comcast-dot-net.invalid> writes:
> On 1/10/2013 6:37 AM, Jukka Lahtinen wrote:
>> Daniel Pitts <newsgroup.nospam@virtualinfinity.net> writes:
>>> On 1/9/13 2:51 PM, Lew wrote:
>>>> '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.
>> 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);
> }
> }
This is an example of what I wrote above. You need that synchronization
to prevent others from modifying sb between the charAt, length and
deletCharAt calls anyway.
Using StringBuffer instead of StringBuilder does NOT accomplish that.
> // 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.
Neither is using StringBuffer.
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.
--
Jukka Lahtinen
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