This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: [PATCH] PR/12647: MinGW: Respect refcount in _Jv_CondWait
- From: Mohan Embar <gnustuff at thisiscool dot com>
- To: tromey at redhat dot com
- Cc: java-patches at gcc dot gnu dot org
- Date: Thu, 23 Oct 2003 17:42:02 -0500
- Subject: Re: [PATCH] PR/12647: MinGW: Respect refcount in _Jv_CondWait
- Reply-to: gnustuff at thisiscool dot com
Hi Tom,
>Mohan> If I don't hear from anyone in a few days, I'll
>Mohan> check this in. (I still prefer letting things
>Mohan> sit for awhile so people can catch any formatting
>Mohan> errors and stuff.)
>
>Mohan> + while (curcount > 0)
>Mohan> + {
>Mohan> + _Jv_MutexUnlock (mu);
>Mohan> + --curcount;
>Mohan> + }
>
>I looked through the code a bit. I notice that _Jv_MutexLock enters
>the critical section with each call. But really, don't we only need
>to do that once, since we're explicitly keeping the lock count?
>
>It seems to me that this code could work along the lines of the POSIX
>code. And then in this case the above could be simplified; see
>posix-threads.h and posix-threads.cc.
I could go either way on this. pthread_mutex_init creates a fast mutex
on Linux by default, whereas Win32 InitializeCriticalSection() always
creates a recursive mutex. Part of me likes the simplicity of your solution,
but part of me says that by leaving the Windows code the way it is, we
could potentially more easily catch future errors in the library which
don't have matching _Jv_MutexLock / _Jv_MutexUnlock calls.
I'll let you and others cast the deciding vote.
-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/