Prev: Shop online without credit card
Next: ANNOUNCE: Major Feature Release - NHI1-0.7, PLMK-1.6 and libmsgque-4.5
From: Arne Vajhøj on 7 Mar 2010 12:17
On 07-03-2010 12:07, markspace wrote:
> Peter Duniho wrote:
>> 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.

What is thread safe by single thread?

I agree with:

http://en.wikipedia.org/wiki/Thread_safe

"A piece of code is thread-safe if it functions correctly during
simultaneous execution by multiple threads."

Thread safety as a concept relates to multiple threads.

Arne
From: Mike Schilling on 7 Mar 2010 12:22
endymion wrote:
> 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?

It would be odd as hell for a static factory method not to be thread-safe.
But since this isn't documented anywhere, let's have a look at the source
code (for 1.5.0_16-b02):

public static Calendar getInstance()
{
Calendar cal = createCalendar(TimeZone.getDefaultRef(),
Locale.getDefault());
cal.sharedZone = true;
return cal;
}

private static Calendar createCalendar(TimeZone zone,
Locale aLocale)
{
// If the specified locale is a Thai locale, returns a
BuddhistCalendar
// instance.
if ("th".equals(aLocale.getLanguage())
&& ("TH".equals(aLocale.getCountry()))) {
return new sun.util.BuddhistCalendar(zone, aLocale);
}

// else create the default calendar
return new GregorianCalendar(zone, aLocale);
}

Not much doubt that it always returns a newly constructed one. If the
version you're using might return the same Calendar twice, it has a pretty
significant bug in it.


From: markspace on 7 Mar 2010 12:52
Arne Vajh�j wrote:
> On 07-03-2010 12:07, markspace wrote:
>> Peter Duniho wrote:
>>> 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.
>
> What is thread safe by single thread?


I'll give you a counter example: Most Swing methods are NOT thread safe
for a single thread to call, since they interact with the EDT and will
not synchronize properly between the caller and the EDT.

Let me try to explain my idea a bit more:

Given some method a(), if the results of a() are visible to the calling
thread (all object properly constructed, any threads started by the
method synchronize properly with objects they interact with, etc.) then
a() is safe for a single thread to call.

If the results are not visible (objects are NOT properly created) then
that method isn't safe. Again, using Swing:

public void createAndShowGui() {
JFrame frame = new JFrame( "Not safe." );
frame.add( new Label( "This isn't safe" ) );
frame.pack();
frame.setVisible( true );
}

This method is not safe to call, since it doesn't synchronize with the
EDT, and the objects aren't created in a thread safe manner. It's not
safe for even one thread to call without special consideration (being
called on the EDT).

Another example might be a method which uses a persistence layer to
makes database calls, perhaps on a separate thread. That method is
responsible for making sure all objects created or interacted with are
visible to the calling thread, or else document what the calling thread
has to do to make those objects visible.

Brian Goetz talks about this in Java Concurrency in Practice, that
single-thread safety is the default. Anything different must be documented.

From: Arne Vajhøj on 7 Mar 2010 14:13
On 07-03-2010 12:52, markspace wrote:
> Arne Vajh�j wrote:
>> On 07-03-2010 12:07, markspace wrote:
>>> Peter Duniho wrote:
>>>> 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.
>>
>> What is thread safe by single thread?
>
> I'll give you a counter example: Most Swing methods are NOT thread safe
> for a single thread to call, since they interact with the EDT and will
> not synchronize properly between the caller and the EDT.

my thread + EDT = single thread

????

> Let me try to explain my idea a bit more:
>
> Given some method a(), if the results of a() are visible to the calling
> thread (all object properly constructed, any threads started by the
> method synchronize properly with objects they interact with, etc.) then
> a() is safe for a single thread to call.

If the code in a() is thread safe then a() is thread safe. That
is hardly surprising.

> Brian Goetz talks about this in Java Concurrency in Practice, that
> single-thread safety is the default. Anything different must be documented.

It is reasonable to expect that the library does not start any threads
working on the objects unless the documentation state so.

But I still don't see much point in considering a single thread
scenario for thread safe.

Arne

From: Peter Duniho on 7 Mar 2010 16:08
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. As Arne says, the idea of "thread safe" pertains
only to multi-thread scenarios. 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.

Pete
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