This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] PR/12647: MinGW: Respect refcount in _Jv_CondWait


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/




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]