This is an idea using automatic cleanup of interfaces: procedure foo; <- lock begin synchronize(cs); [...] end; <- unlock
or procedure foo; <- lock begin with synchronize(cs) do <- lock begin [...] end; <- unlock end; { TLock } type TLock = class(TInterfacedObject) private FCriticalSection: TCriticalSection; public constructor Create(cs: TCriticalSection); virtual; destructor Destroy; override; end; constructor TLock.Create(cs: TCriticalSection); begin FCriticalSection := cs; cs.Acquire; end; destructor TLock.Destroy; begin FCriticalSection.Release; inherited; end; function synchronize(cs: TCriticalSection): IUnknown; begin Result := TLock.Create(cs); end; 2008/7/31 tom_at_work <[EMAIL PROTECTED]> > Hello, > > Am 31.07.2008 um 11:56 schrieb Florian Klaempfl: > > Vinzent Höfler schrieb: >> >>> -------- Original-Nachricht ------- >>> OTOH, it's looks about the same as in Java and even Java now has >>> explicit Locks, because "synchronized" simply isn't efficient nor >>> flexible enough... ;) >>> >> >> Since I don't use java, what's the difference to locks? >> >> > In practice imo not too much, synchronized is just a convenience > functionality, exactly like the one you proposed. > > In short the difference: > > Java always locks on monitors i.e. guards which are available for any > object; Pre 1.5 the only way to lock was using some syntax additions. The > syntax allows per method (class or instance) or per block scope, i.e. > > synchronized void doSomething() { ... } // method level: monitor object is > either "this" or this.class object > > void doSomething() { > ... > synchronized (monitor) { // on block level; monitor object is "this" if > not specified otherwise the given object > } > ... > } > > With 1.5 they added a "Lock" interface which provides the usual > lock()/trylock()/unlock() methods which should be self-explaining. > This for example allows interlocked locks if required > > lock1.lock(); > ... > lock2.lock(); > ... > lock1.unlock(); > ... > lock2.unlock(); > > > Hth, > Thomas_______________________________________________ > > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel >
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel