No, you can't remove that lock. The lock in the get method is to
synchronize the lazy eval of the message loader. The lock in the other call
is to synchronize the loading of message text.
And, even if you could get away with it there you'd still have problems
down the line because our platform semanteics require that mutexes be
reentrant, as they are on most platforms. If your platform does not support
reentrant mutexes, then you must fake it. Look at the platform
implementation of mutexes for Solaris, which has the same problem. Its not
very much effort to do.
----------------------------------------
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
[EMAIL PROTECTED]
[EMAIL PROTECTED] (Steven G. Parker) on 03/15/2000 12:24:20 AM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: Deadlock
I am experiencing a deadlock in some of the sample programs when I turn
on -v. It happens when this section of XMLValidator.cpp (line 154 in
1.1.0)
gets called:
XMLMutexLock lockInit(&gValidatorMutex());
if (!getMsgLoader().loadMsg(toEmit, errText, maxChars, text1,
text2, text3, text4))
Then, in getMsgLoader (line 125 in my version), the gValidatorMutex gets
locked again:
XMLMutexLock lockInit(&gValidatorMutex());
which of course, deadlocks the program.
Looking at the three calls to getMsgLoader(), the mutex is always acquired
before getMsgLoader is called, so it would be safe to remove the lock from
getMsgLoader().
Is this the right thing to do?
Steve
