On Thu, 17 Nov 2011, Zoltan Herczeg wrote:
> And there is an SLJIT_CALLOC somewhere,
Perhaps there used to be but not any longer? I was a bit surprised
that there wasn't a realloc() in there too.
> Btw do you know about a static mutex under Windows? If the mutex handle alloction fail now, it might cause trouble...
The probabality of failure creating the two simple mutexes is very low.
If resourses were that critical then the application will experience
other problems very soon afterwards. Perhaps allocator_grab_lock() and
sljit_grab_lock() functions could return a BOOL whereby a controlled
failure could propagate back out of PCRE and let the resource issues
flare up outside of it. Doing that provides "it's not my fault" but
of course can't fix the underlying problem.
The mutexes seem like a good implementation. Only because you asked
an alternative is illustrated below. The code should work because:
+ InterlockedIncrement() returns the thread-safe incremented value.
+ Sleep(0) causes the thread to relinquish its execution time slice.
static LONG l_LockValue = 0L;
/* obtaining the lock */
while (InterlockedIncrement(&l_LockValue) != 1L)
{
InterlockedDecrement(&l_LockValue);
Sleep(0);
}
/* here the lock has been obtained */
/* Later, releasing the lock is just a matter of: */
InterlockedDecrement(&l_LockValue);
If the compilation was for single-thread then InterlockedIncrement()
has no thread considerations to worry about. In that situation it is
implemented by the C compiler as if the code was (++l_LockValue).
Without Sleep(0) the loop would burn CPU inefficiently. The assumption
is that there exists other thread(s) of similar priority that will gain
the relinquished time, including the one that obtained the lock. That
seems almost 100% probable in the cases where JIT would encounter the
need for its locks. Yet if all other of the application's threads were
assigned a lower thread priority than the one that's looping, then the
CPU will burn.
IMHO the JIT Windows mutexes are at least as good as any alternative.
Regards,
Graycode
