<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 16 Feb 2012, at 23:56, David Jenkins wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Monaco; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="font-family: monospace; ">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).<br><br>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.<br></span></span></blockquote></div><br><div><a href="http://edn.embarcadero.com/article/28258">http://edn.embarcadero.com/article/28258</a> 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.</div><div><br></div><div><br></div><div>Jonas</div></body></html>