On Thu, 2006-01-19 at 17:17 +1300, Simon Kitching wrote:
> On Wed, 2006-01-18 at 22:18 +0000, robert burrell donkin wrote:
> > on the subject of thread safety, there is a potential issue with
> > Log4JLogger - take a look at getLogger(). i'd like a second opinion (and
> > a third and a forth, if possible) so i'll post this now before i analyse
> > it.
> >
> > (see
> > http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200511.mbox/[EMAIL
> > PROTECTED])
> >
>
> I don't think this is valid. Yes there is a race condition but it's
> harmless.
<snip>
> NB: the synchronized keyword also ensures that CPU caches are correctly
> synchronized. However even taking this into account I can't see a
> situation where anything bad can happen.
i was wondering whether a logger could be partially constructed and if
so what the likely effect would be (thread A enters getLogger() and
starts the construction of the logger but is not finished before thread
B enters the method and finds logger has been assigned (so not null) but
not completed constructed.) i'm unsure whether this scenario is allowed
by the java language and virtual machine specifications. a few similarly
unintuitive ones are.
finding out the answer would probably require spending a good few hours
analysing the specifications. i'm not sure that this is a priority for
me right now (since i suspect that this would have been reported had it
been a practical scenario). any volunteers?
if this is a real problem then it could be fixed by assigning to a
temporary variable:
public Logger getLogger() {
Logger logger = this.logger;
if (logger == null) {
logger = Logger.getLogger(name);
}
this.logger = logger;
return (this.logger);
}
but it's probably best to err on the side of inertia if we aren't sure
that the issue is real...
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
