Re: Possible code simplification and optimisation

[David Ayers]

Richard Frith-Macdonald wrote:

> I've written a couple of classes - GSLazyLock and GSLazyRecursiveLock 
> (subclasses of NSLock and NSRecursiveLock).
>
> The idea of these is to be used to simplify stuff a bit with respect 
> to threading - If we have a single threaded application, we don't want 
> to waste time locking/unlocking mutexes pointlessly, but if we become 
> multithreaded, we want any classes that need locks to have those locks 
> in the correct state.

Sounds good to me!

> So, a GSLazyLock keeps track of its own state in a BOOL, and 
> metamorphoses into an NSLock when the program becomes multithreaded,
> while a GSRecursiveLock keeps track of the number of times it has been 
> locked in a counter.
> Classes using these locks can therefore be coded with no need to be 
> aware of whether the program is running in single or multi-threaded mode.

So when an process becomes multithreaded and the GSLazyLock is in a 
locked state, it would morph into an NSLock and also be sent a -lock 
message.  And the NSRecursiveLock would be sent as many -locks as it's 
previous GSLazyRecursiveLock counterpart... very good!

> Now -
> I could add these as private classes and use them internally in the 
> base library
> or I could add them as public classes in the Additions part of the 
> base library

I think this would be a very useful addition to -base(add).

> or I could change the existing NSLock/NSRecursiveLock classes so that 
> they do the same sort of thing.

Hmm.  I think this maybe suboptimal.  If people rely on this behavior 
for GNUstep apps they're just in for trouble when developing 
crossplattform.  (Eventhough the "only" trouble would be excess locking 
on OS X.)

Let's take GDL2/GSWeb for example.  If we relied on GNUstep behavior and 
used NS*Lock then GDL2 and GSWeb on OS X will probably be a lot slower 
than on GNUstep.  On the other hand, if we used GS*Lock of Additions 
that morphed to NS*Lock of either -base or Foundation, we'd have the 
feature in both worlds.

So I'd prefer 2.

Cheers,
David