Prev: Shop online without credit card
Next: ANNOUNCE: Major Feature Release - NHI1-0.7, PLMK-1.6 and libmsgque-4.5
From: endymion on 7 Mar 2010 10:59
Hi,

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

I use Calendar to do operations on dates, and as I see no obvious bug in the
code, and as the problem occurs randomly and after a certain time, I was
wondering if that was a multi-threading issue.

So the question is: Is Calendar.getInstance() thread safe?

I did not find a satisfying answer searching the web.

Is there asbolutely no possibility that two (or more) threads calling
Calendar.getInstance() at the same time get the same Calendar object?

In my code I do the following:

Calendar calendar = Calendar.getInstance();
calendar.add(Calendar.MINUTE, amount);
[...]

Thanks for your answers.

Christophe B.

From: markspace on 7 Mar 2010 11:13
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?


> In my code I do the following:
>
> Calendar calendar = Calendar.getInstance();
> calendar.add(Calendar.MINUTE, amount);


"getInstance()" doesn't say it returns a new instance, but I don't see
how it could not. I think it is more likely that:

1. "amount" above is set to an incorrect value. Do you range check it?

2. The "calendar" object is getting set incorrectly after this line
(i.e., it's in the code you aren't showing us). OBJECTS are never
thread safe unless you make them so, and that discounts the possibility
of simple logic errors (i.e., you set the value of "calendar" to a
negative value somewhere else in your code).


I think we need to see some code that actually reproduces the problem.
If you can make an SSCCE that shows us the error, we'll take a look at it.

http://sscce.org/

From: Peter Duniho on 7 Mar 2010 11:34
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: Arne Vajhøj on 7 Mar 2010 11:42
On 07-03-2010 11:13, 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?

Maybe for a static method like this. It is not very obvious to
synchronize on the Calendar class.

But in general (for instance methods) I would make the opposite
assumption: unless the doc states that it is thread safe, then
I will assume that it is not.

Arne

From: markspace on 7 Mar 2010 12:07
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.
>


Synchronizing on what? Synchronization requires a shared object to be
effective. If you synchronize on ObjectA, and the body of some method
you call synchronizes on ObjectB, then nothing has been done and no
synchronization occurs.

If the method does not document what object you need to synchronize on,
then you can't do anything with it.

I think you know this, and maybe we are talking at cross purposes. What
I mean by "thread safe" here is that a method can be called safely by a
single thread. If you can't do that, then you can't make the call. The
OP doesn't seem to be implying anything different. He says he has
multiple threads, but doesn't provide any interaction between them other
than making one method call. Well, yes, that has to be safe, or no
thread at all could call the method. If it were not safe, like Java's
Swing methods, then it should be documented.


> I doubt the Calendar class is thread-safe, except possibly static
> methods like getInstance(). Typically, classes are NOT thread-safe
> unless documented otherwise.


By a single thread, sure, they must be. Objects aren't thread safe by
default. I see what you are saying, but sometimes I think people get
confused as to what thread safety really means, or does.

There's an implicit guarantee in all methods that they are safe to call
from a single thread. You have to have that or the method is just
broken. And that's all the OP has shown us, is a single method call by
a single thread. That much is always "thread safe."


 |  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