On 10/3/06, Jacob Atzen <[EMAIL PROTECTED]> wrote: > I have no idea how Mutex handles locking, but sync seems to be doing a > whole lot of work over and over again. It seems to me it's really meant > for smaller locking queues.
They handle locking in more or less the same way. What is really substantially different is the unlocking. Sync goes and wakes up the entire queue of waiting threads. They scramble for the lock again, and all but one (probably the first one to be woken up) fail to get it and are relocked. If you have a big thread queue, it is a lot of extra work. Mutex, on the other hand, just handles it one thread at a time, so it is _MUCH_ more efficient with the unlocking. > In regards to the sync issues the jury is still out on that one. I will > need to get a deeper understanding of how sync works to get to the > bottom of it, but I'll continue poking around. That with Mutex. It't very simple to understand. Then go take a look at Sync. You have to shift through an uglier, more antiquated coding style, and there is a bunch of extra code to deal with the different types of locks that Sync supports, but if you filter through that to find the lock and unlock pieces of code for exclusive locks, you'll quickly start to understand the differences. Mutex is also so very simple that you'll see why I prefer to use a custom version that works around the Array memory mismanagement that bites the standard one over Sync, which is ugly enough to make the baby Jesus cry. Kirk Haines _______________________________________________ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
