[Mongrel] The real reason why Sync and Mutex behave differently
wyhaines at gmail.com
Tue Sep 5 17:20:56 EDT 2006
On 9/5/06, Luis Lavena <luislavena at gmail.com> wrote:
> Anyway, the use of thread.critical isn't a viable locking method, as
> said by ruby-core by matz a few years back (1.6 version I think).
Thread.critical alone makes it easy to get oneself into trouble, but
both Sync and Mutex are built on top of it.
> The really funny part is that, based on your interpretation of the
> problem, why the GC of both platforms behave differently?
I think the differences observed between Linux and WinXP relate to how
each platform's memory management interacts with Ruby.
BTW, although switching Mutex to using a linked list for the thread
queue worked great, it appears that one can get Ruby to do reasonable
things with the array by switching the push in lock and the shift in
unlock to be an unshift and a pop, respectively. This is because pop
will realloc the array.
I haven't yet tested that as extensively as I did the mutex with
linked list, but so far it appears solid.
> I know that ruby GC isn't the fastest, nor the optimal (nor even as
> good as other, simplistic GC around the net). The whole mark and sweep
> method is too "intensive".
> But, why the differences between platforms? even as you said what do
> Mutex and what do Sync... ruby-mswin32 (stable from official build,
> vc6) do garbage collect of Mutex when linux doesn't?
That really just looks like a difference in platform memory management
interaction with Ruby. The fixes (linked list or changing array
operations) both appear to work identially on Linux and WinXP, though,
without incurring the speed penalty that Sync has.
I'm doing more testing this week, though, on both Linux and WinXP.
I'll send out updates here and on ruby-talk if I find anything else
that is useful or interesting.
More information about the Mongrel-users