On May 31, 2012, at 10:59 PM, Antonio Nunes wrote:
> On 1 Jun 2012, at 02:34, Charles Srstka wrote:
>
>> static dispatch_once_t onceToken;
>> dispatch_once(&onceToken, ^{
>> myVLFContext = [[VLFContext alloc] init];
>> });
>>
>> @synchronized(myVLFContext) {
>> ...
>> }
>
> That does seem better. Any reason though to create a custom class? Couldn't
> we just [[NSObject alloc] init]? I think @synchronized cares about pointer
> uniqueness, not about the class, no? (And, as I learned from this, under ARC
> the pointer should also actually respond to memory management methods, i.e.
> be a real object, which is satisfied simply by it pointing to an object of
> class NSObject.)
Indeed this is the case. The VLFContext thing being in there came from my
basing my reply on the pseudocode snippet the previous person posted — just
replacing the simple test against nil with dispatch_once.
>> If you keep having trouble with @synchronized, though, I’d recommend just
>> switching to a pthread_mutex_t, a spin lock, or dispatch_sync. Any of these
>> should have better performance than @synchronized anyway.
>
> I'd already solved the issue with @synchronized, but am indeed considering
> switching to pthread_mutex_t or dispatch_sync, although I think the practical
> performance gains will be marginal.
If it’s working with acceptable performance, then it might be good enough. If
you’re having problems, or if performance leaves something to be desired, then
it’s not a bad idea to look into the other methods.
Charles
_______________________________________________
Cocoa-dev mailing list ([email protected])
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 [email protected]
