Hi,

The current TMultiReadExclusiveWriteSynchronizer as implemented in FPC 2.3.1 is wrong. It use Critical Sections in a standard way which means it blocks all other threads while one thread is doing a Read. This is wrong. It is a MULTI read, SINGLE write synchronizer. So it must only block other thread is a Write is in progress. But allow multiple reads while no Write is in progress.

The TMultiReadExclusiveWriteSynchronizer is currently equivalent to the Delphi 7 TSimpleRWSync class, not the Delphi
TMultiReadExclusiveWriteSynchronizer class.

I have a corrected TMultiReadExclusiveWriteSynchronizer implementation (don't worry, not based on Delphi implementation) that I can donate to FPC. I just need confirmation that the current implementation in FPC is incorrect though.

Regards,
- Graeme -

It is on the safe side but it is not optimal.

If you have a better for unix this will be fine. IIRC it is not easy (if possible after all?) to implement TMultiReadExclusiveWriteSynchronizer for unix systems.

Florian Klaempfl wrote

If you have a better for unix this will be fine. IIRC it is not easy (if possible after all?) to implement TMultiReadExclusiveWriteSynchronizer for unix systems.

What's wrong with these routines: pthread_rwlock_init, pthread_rwlock_rdlock/pthread_rwlock_wrlock, pthread_rwlock_unlock, pthread_rwlock_destroy?

Jonas

I simply don't know but I thought there was a reason it could have been also something like kylix compatibility.

Graeme Geldenhuys :

I have a corrected TMultiReadExclusiveWriteSynchronizer implementation (don't worry, not based on Delphi implementation) that I can donate to FPC.

I hope it isn't based on the Delphi one. Last time I heard the Delphi implementation suffers from occasional dead locks.

So any such implementation should be reviews very thouroughly. ;)

I just need confirmation that the current implementation in FPC is incorrect though.

It's not incorrect, just inefficient.

Vinzent.

Florian Klaempfl :

If you have a better for unix this will be fine. IIRC it is not easy (if possible after all?) to implement TMultiReadExclusiveWriteSynchronizer for unix systems.

It's possible, yes. If it's possible in an efficient way, is another question.

Vinzent.

In our previous episode, Florian Klaempfl said:

Afaik there is a document on the net about an implementation on Solaris.

If you read my mail (as quoted above), I clearly stated that it is NOT based on the Delphi one. After all, I brought to attention the Delphi similarities in the FPC code a while back - so I would not introduce copyright code into FPC.

> I just need confirmation that the current implementation in FPC is > incorrect though. It's not incorrect, just inefficient.

I have to disagree. The currently class name is
TMultiReadExclusiveWriteSynchronizer. The currently implementation does NOT allow multi-read (so the class name totally misleading). It uses a simple Critical Section to block any other threads while reading or writing.

At least, the FPC team needs to rename the class to TSimpleRWSync (to be Delphi compatible with the same functionality).

Regards,
- Graeme -

In our previous episode, Graeme Geldenhuys said:

This is already known since the beginning. It is just an initial implementation to ease porting.

At least, the FPC team needs to rename the class to TSimpleRWSync (to be Delphi compatible with the same functionality).

Sure. I didn't know TSimple*, otherwise i'd suggest to simply delete it, it was always meant as a placeholder.

But only when there is a validated, portable substitute. Since though limited and inefficient, the current implementation keeps codebases running.