[fpc-devel] Re: Multi threading support

[Boian Mitov]

  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 <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





------------------------------------------------------------------------------


  _______________________________________________
  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/41e1413f/attachment.html>