Prev: Shop online without credit card
Next: ANNOUNCE: Major Feature Release - NHI1-0.7, PLMK-1.6 and libmsgque-4.5
From: Christophe B. on 7 Mar 2010 16:48
Well, to the question: "is getInstance thread safe?", the answer is yes and
I thank you all for your help.

I guess I have to conclude that the odd behaviour I get is related to my own
code rather than Java's Calendar class.
I would have prefered the mistake to be in Java standard API's, but... ;-)

So, I'll try to have a SSCCE, and that's what I should have done at the
beginning.

Thanks again for your answers and the interesting discussion on thread
safety.

Christophe B.

Peter Duniho wrote:

> markspace wrote:
>> endymion wrote:
>>
>>> So the question is: Is Calendar.getInstance() thread safe?
>>
>>
>> I think you have to assume all methods are thread safe unless there is
>> documentation to the contrary. How could you call any method reliably
>> unless it was deemed to be safe to do so?
>
> By synchronizing when you need to call them simultaneously from multiple
> threads.
>
> I doubt the Calendar class is thread-safe, except possibly static
> methods like getInstance(). Typically, classes are NOT thread-safe
> unless documented otherwise.
>
> That said, I agree with the rest of your comments. The Calendar class
> is mutable, so it wouldn't make sense if the "getInstance()" overloads
> didn't create new instances each time they are called. So while not
> explicitly stated, simply by virtue of how they work, those methods
> should be thread-safe without any explicit implementation to make them so.
>
> And indeed, if you look at the source code for the java.util.Calendar
> class, the getInstance() methods call a private static method
> createCalendar(), the essence of which is simply to use "new" to create
> a new instance. And "new" is definitely thread-safe.
>
> So if there's a thread-safety bug, it's probably in the OP's code, which
> of course without a concise-but-complete code example (SSCCE) we would
> not be able to point out.
>
> Pete

From: markspace on 7 Mar 2010 17:09
Peter Duniho wrote:
> markspace wrote:
>> [...]
>> Brian Goetz talks about this in Java Concurrency in Practice, that
>> single-thread safety is the default. Anything different must be
>> documented.
>
> Surely by that he specifically means that the default is for a class to
> NOT be thread-safe.


No he meant what I wrote. His exact discussion concerned the database
driver object, which is well known to be multi-threaded, but doesn't
document its thread safety. In fact, there were a few buggy
implementations which weren't safe for a single thread to execute.
Which was his whole point: in the absence of documentation, you have to
assume that method invocation is safe for a single thread. That's for
the caller and the implementer both.

I'll look up the chapter if you're interested in a reference, but it's
pretty easy to find too if you have a copy.

Second point: I said "method" (and so did the OP), you said class.
There's a difference. I'm only talking about the invocation of a single
method call by a single thread here.

>
> As Arne says, the idea of "thread safe" pertains
> only to multi-thread scenarios.


Which is possible to have multiple threads even if you have only one
thread yourself.


> ALL code is trivially thread safe for
> single-thread scenarios, and calling code "thread safe" but qualified to
> only the single-thread scenario makes no sense.


'cept for that Swing method I showed, and that buggy driver
implementation I mentioned, and ....
From: Roedy Green on 8 Mar 2010 00:20
On Sun, 07 Mar 2010 16:59:57 +0100, endymion <pubcb84(a)free.fr> wrote,
quoted or indirectly quoted someone who said :

>
>In a multi-threaded application, I encountered problems with dates being
>"reset" to 1970, or being negative when converted into ms since 1970.

I have got in trouble with SimpleDateFormat not being thread safe.
Don't make them static unless you have but a single thread.
--
Roedy Green Canadian Mind Products
http://mindprod.com

The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.
~ Tom Cargill
From: Lothar Kimmeringer on 9 Mar 2010 07:19
Roedy Green wrote:

> I have got in trouble with SimpleDateFormat not being thread safe.

How possibly _could_ a SimpleDateFormat be thread safe?


Regards, Lothar
--
Lothar Kimmeringer E-Mail: spamfang(a)kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
From: Mayeul on 9 Mar 2010 08:13
Lothar Kimmeringer wrote:
> Roedy Green wrote:
>
>> I have got in trouble with SimpleDateFormat not being thread safe.
>
> How possibly _could_ a SimpleDateFormat be thread safe?

?

What do you mean ? It looks to me if SimpleDateFormat had been designed
immutable, it would make sense to have it thread-safe, as other
languages or libraries have it.

Actually, even though its mutable, I would have expected it to be
thread-safe as long as you don't mutate it anymore. Thankfully the
JavaDoc is clear that it's not. Oh well.

--
Mayeul
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Shop online without credit card
Next: ANNOUNCE: Major Feature Release - NHI1-0.7, PLMK-1.6 and libmsgque-4.5