Thanks. I missed the recursive mutex part. That should fix the problem. Thanks again, Steve
On Mar 15, 11:21am, [EMAIL PROTECTED] wrote: > Subject: Re: Deadlock > > > > 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 > > > >-- End of excerpt from [EMAIL PROTECTED]
