Re: sync.m

[David Chisnall]

I've now fixed this case in libobjc2.  Unfortunately, someone decided to 
'helpfully' reindent the version of ObjectiveC2.framework in GNUstep, which 
means that diffs from libobjc2 no longer cleanly apply in ObjectiveC2 (nor to 
diffs against the original version in Étoilé svn), so whoever did that gets to 
volunteer to back-port the changes.  

On 27 Feb 2010, at 17:40, Richard Frith-Macdonald wrote:

> You are probably in a better position than anyone else to be aware of 
> precisely what parts of ObjectiveC-2 are most efficient or inefficient, and 
> how they compare to the traditional ways of doing things.  Have you 
> considered producing a paper describing those differences?  If we had them 
> quantified we would have a really good guide for people to know when to use 
> new features and when to avoid them (and when it really doesn't matter).


Well, I did write a book that describes them...

@synchronized is basically impossible to implement efficiently.  It's a stupid 
feature added to make life easier for Java programmers who are too lazy to 
think when they learn a new language.  There are basically three ways you can 
do it:

1) Allocate a pthread_mutex_t with every object

Pros: Fast, simple
Cons: Wastes at least one word of memory for every object, including the 99.9% 
that are never used as arguments to @synchronized().

2) Have a shadow data structure mapping objects to locks.

Pros: Doesn't waste much memory.
Cons: Extra locking on the shadow structure needed, extra code needed to remove 
locks when they are no longer needed, overhead performing the lookup.

3) Add a hidden class between the object and its real class which stores the 
lock.

Pros: Relatively simple and non-invasive.
Cons: Needs an extra class structure for every locked object.

libobjc2 / ObjectiveC2.framework use option 3.  We use 
objc_allocateClassPair(), which doesn't work for creating just a new metaclass 
(although we fail slightly more gracefully than Apple's version, which just 
returns a pointer to a random address).  I've now added a special case to 
libobjc2 and a non-portable runtime function for allocating just a new 
metaclass.  

In all cases, this pattern will be much faster:

[nslock lock];
@try {
        // do stuff
} @finally {
        [nslock unlock];
}

It's also worth remembering that @synchronized uses a recursive mutex, which, 
on most platforms, is slower than the non-recursive form used by NSLock.  
Unless you actually need the recursive behaviour, don't use it.  

@synchronized is a horrendous language feature, because it looks just like the 
Java keyword, but has almost the exact opposite performance characteristics.  

David

-- Sent from my Difference Engine