Thanks for the great explanation Brian. Having a dual-processor system is a need for my app, so that's why I chose SpinLocks. But using dispatch blocks is could be an other option, I guess.
On Mar 8, 2012, at 8:19 PM, Brian Lambert wrote: > Spin locks are useful in certain situations. > > First of all, on a single-processor system, it's never a good idea to use a > spin lock because all it will do is burn up the waiting thread's scheduling > quantum while preventing a thread that's holding the lock from getting > scheduled so that it can complete its work and release the lock. > > A spin lock is useful in multi-processor environments when you know that a > lock will be held for a *very short period of time*. In this case, spin > locks can help you avoid excessive context switching because a waiting > thread will often be able to spin (do something else) while waiting for a > lock to be released, acquire the lock, and do its work, all within its > scheduling quantum. > > In many simple scenarios, especially when contention is very low, > @synchronized will be the best choice because it's trivial to get right and > high-performance. > > In other scenarios, a fair readers-writers lock will be ideal. > > > On Thu, Mar 8, 2012 at 9:52 AM, Jan E. Schotsman <jesc...@xs4all.nl> wrote: > >> >> On Mar 8, 2012, at 3:22 PM, CoGe - Tamas Nagy wrote: >> >> Maybe this will helps you, here is my thread-safe subclass of >>> NSMutableArray: http://code.google.com/p/**cogeopensource/source/browse/* >>> *trunk/CoGeOpenSource/**CoGeThreadSafeMutableArray.m<http://code.google.com/p/cogeopensource/source/browse/trunk/CoGeOpenSource/CoGeThreadSafeMutableArray.m> >>> >> >> Thanks for the code. >> I have two questions: >> >> 1. If you believe that OSSpinLock is faster than NSLock why don't you use >> it for your thread-safe mutable array class too? >> >> 2. Once you start using an enumerator for the array you probably need a >> explicit mutex after all. Isn't it simpler to just use >> @synchronized(array) wherever the array is accessed? >> >> Jan E. >> >> ______________________________**_________________ >> >> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >> >> Please do not post admin requests or moderator comments to the list. >> Contact the moderators at >> cocoa-dev-admins(at)lists.**apple.com<http://lists.apple.com> >> >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/**mailman/options/cocoa-dev/** >> brianlambert%40gmail.com<https://lists.apple.com/mailman/options/cocoa-dev/brianlambert%40gmail.com> >> >> This email sent to brianlamb...@gmail.com >> > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/info%40cogevj.hu > > This email sent to i...@cogevj.hu Tamas Nagy ----------------- CoGe VJ Software http://cogevj.hu i...@cogevj.hu _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
