Calendar.getInstance() thread safe?
in [Java Help]
|
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 |