[fpc-devel] TMultiReadExclusiveWriteSynchronizer

2012-02-17 Thread David Jenkins 
Under Delphi if the TMultiReadExclusiveWriteSynchronizer writelock is 
held a read is not blocked if the ThreadID for the read is the same as 
the ThreadID for the write.  Under FreePascal if writelock is held the 
read is always blocked regardless of ThreadID or anything else 
(implemented in the BeginRead method).


I have some third party code that assumes that 
TMultiReadExclusiveWriteSynchronizer will work as it does in Delphi.  I 
am wondering if the freepascal implementation is purposeful (read block 
even when in same thread is intentional) and I should talk to my third 
party vendor.  Or if this is something that could/should be addressed in 
FreePascal.


Thanks

David Jenkins
Scooter Software


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] TMultiReadExclusiveWriteSynchronizer

2012-02-17 Thread Jonas Maebe 


On 16 Feb 2012, at 23:56, David Jenkins wrote:

Under Delphi if the TMultiReadExclusiveWriteSynchronizer writelock  
is held a read is not blocked if the ThreadID for the read is the  
same as the ThreadID for the write.  Under FreePascal if writelock  
is held the read is always blocked regardless of ThreadID or  
anything else (implemented in the BeginRead method).


I have some third party code that assumes that  
TMultiReadExclusiveWriteSynchronizer will work as it does in  
Delphi.  I am wondering if the freepascal implementation is  
purposeful (read block even when in same thread is intentional) and  
I should talk to my third party vendor.  Or if this is something  
that could/should be addressed in FreePascal.


http://edn.embarcadero.com/article/28258 indicates that promoting read  
locks to write locks should work by design (which the current FPC  
implementation doesn't support either), so it's logical to assume that  
acquiring a read lock while you hold a write lock should also be  
possible. Feel free to file a bug report.



Jonas___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] TMultiReadExclusiveWriteSynchronizer does not allow read lock promoting to a write lock

2010-02-22 Thread Inoussa OUEDRAOGO 
2010/2/19 Nikolai Zhubr n-a-zh...@yandex.ru:
 19.02.2010 23:02, Inoussa OUEDRAOGO:

 Hi

 The TMultiReadExclusiveWriteSynchronizer implementation does not allow
 read lock promoting
 to a write lock. The program above hang in FPC 2.4 and 2.5.x while
 working in Delphi and
 FPC 2.2.x. It hangs at the x.Beginwrite(); instruction. The
 implementation clearly does
 not support this scenario. It will be helpfull to note this in the
 documentation.

 AFAIK entering exclusive lock without releasing multiple-read lock is very
 unsafe regarding deadlocks (Almost deadlock-guaranteed). Of course it is
 safe in the example, but why bother about special 1-thread scenario if
 multithreaded code will be unsafe anyway?

The case here is to note that the FPC 2.4.0 (and trunck)
implementation does not allows lock upgrading while Delphi, FPC 2.2.x
does. This will free people
some debugging time , I talking from experience.   The sample is just
a test case to show the problem.

-- 
Inoussa O.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] TMultiReadExclusiveWriteSynchronizer does not allow read lock promoting to a write lock

2010-02-19 Thread Inoussa OUEDRAOGO 
Hi

The TMultiReadExclusiveWriteSynchronizer implementation does not allow
read lock promoting
to a write lock. The program above hang in FPC 2.4 and 2.5.x while
working in Delphi and
FPC 2.2.x. It hangs at the x.Beginwrite(); instruction. The
implementation clearly does
not support this scenario. It will be helpfull to note this in the
documentation.

code
program test;

{$mode objfpc}{$H+}

uses
  SysUtils;

var
  x : TMultiReadExclusiveWriteSynchronizer;
begin
  x := TMultiReadExclusiveWriteSynchronizer.Create();
  x.Beginread();
WriteLn('Beginread');
x.Beginwrite();
  WriteLn('Beginwrite');
x.Endwrite();
  WriteLn('Endwrite');
  x.Endread();
WriteLn('Endread');

  ReadLn;
end.
/code

-- 
Inoussa O.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] TMultiReadExclusiveWriteSynchronizer does not allow read lock promoting to a write lock

2010-02-19 Thread Nikolai Zhubr 

19.02.2010 23:02, Inoussa OUEDRAOGO:

Hi

The TMultiReadExclusiveWriteSynchronizer implementation does not allow
read lock promoting
to a write lock. The program above hang in FPC 2.4 and 2.5.x while
working in Delphi and
FPC 2.2.x. It hangs at the x.Beginwrite(); instruction. The
implementation clearly does
not support this scenario. It will be helpfull to note this in the
documentation.
AFAIK entering exclusive lock without releasing multiple-read lock is 
very unsafe regarding deadlocks (Almost deadlock-guaranteed). Of course 
it is safe in the example, but why bother about special 1-thread 
scenario if multithreaded code will be unsafe anyway?


Nikolai



code
program test;

{$mode objfpc}{$H+}

uses
   SysUtils;

var
   x : TMultiReadExclusiveWriteSynchronizer;
begin
   x := TMultiReadExclusiveWriteSynchronizer.Create();
   x.Beginread();
 WriteLn('Beginread');
 x.Beginwrite();
   WriteLn('Beginwrite');
 x.Endwrite();
   WriteLn('Endwrite');
   x.Endread();
 WriteLn('Endread');

   ReadLn;
end.
/code



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel