Hmm... it looks almost one to one copy from our code in Version 4.0 of our libraries ;-) . Are you one of our customers, or you have simply come with the same idea as us?
With best regards, Boian Mitov -------------------------------------------------------------------- Mitov Software http://www.mitov.com -------------------------------------------------------------------- ----- Original Message ----- From: Henri Gourvest To: FPC developers' list Sent: Thursday, July 31, 2008 5:57 AM Subject: Re: [fpc-devel] Re: Multi threading support 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
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel