[fpc-devel] Re: Multi threading support

Henri Gourvest hgourvest at progdigy.com
Thu Jul 31 14:57:51 CEST 2008


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 <tom_at_work at gmx.at>

> 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 at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20080731/0e2fb3e3/attachment.html>


More information about the fpc-devel mailing list