 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Starmen
Guest
|
 Posted: Sat Nov 22, 2003 1:27 pm Post subject: TMultiReadExclusiveWriteSynchronizer implementation still b |
 |
|
Hi,
Can anyone confirm the TMultiReadExclusiveWriteSynchronizer implementation
in Delphi 7 is still buggy ? I call the beginwrite / endwrite statements in
the correct order (according to my call log) but it still seems to lock up
after a few calls, waiting to return from the BeginWrite statement.
I know the implementation in the earlier Delphi versions were buggy but I
thought it was fixed in 7 ?
Thx,
Starmen
|
|
| Back to top |
|
 |
Alan Chong
Guest
|
| Posted: Sat Nov 22, 2003 8:48 pm Post subject: Re: TMultiReadExclusiveWriteSynchronizer implementation sti |
|
|
Well, I have the same problem, seems to be borland will never going to
address this problem.
"Starmen" <someone (AT) microsoft (DOT) com> wrote
| Quote: | Hi,
Can anyone confirm the TMultiReadExclusiveWriteSynchronizer
implementation
in Delphi 7 is still buggy ? I call the beginwrite / endwrite statements
in
the correct order (according to my call log) but it still seems to lock up
after a few calls, waiting to return from the BeginWrite statement.
I know the implementation in the earlier Delphi versions were buggy but I
thought it was fixed in 7 ?
Thx,
Starmen
|
|
|
| Back to top |
|
|
Rob Kennedy
Guest
|
| Posted: Sat Nov 22, 2003 11:17 pm Post subject: Re: TMultiReadExclusiveWriteSynchronizer implementation sti |
|
|
Alan Chong wrote:
| Quote: | Well, I have the same problem, seems to be borland will never going
to address this problem.
|
You have the problem in version 6 or version 7? And with the RTL update
packs installed? Have either of you checked QualityCentral to see
whether the problem you're experiencing has been addressed? QC#5115
looks promising.
--
Rob
|
|
| Back to top |
|
|
Starmen
Guest
|
| Posted: Sun Nov 23, 2003 5:37 pm Post subject: Re: TMultiReadExclusiveWriteSynchronizer implementation sti |
|
|
Rob,
Thanks but it looks like it was my sloppy programming (us usual  . I
accidently called 'Endwrite' once too many.
A related question : I don't seem to be able to check whether the
TMultiReadExclusiveWriteSynchronizer object has granted a write lock or not.
I want to call EndWrite in my destructor code to make sure that any locks
accidently left on the object are released so I'd expect some code like
this:
destructor TMyClass.done;
begin
If Synchronizer.WriteLocks > 0 then Synchronizer.EndWrite;
end;
However, I have no way of telling whether there is still a lock or not
because no such variable like 'WriteLocks' exists.
I know that theoretically there can't be any locks left behind if I use the
try... finally.. construction properly, but I want to make absolutely sure
that no thread
will ever lock up the entire system for any reason...
Any ideas ? Create a wrapper class around the
TMultiReadExclusiveWriteSynchronizer class ?
Regards,
Starmen
"Rob Kennedy" <.> wrote
| Quote: | Alan Chong wrote:
Well, I have the same problem, seems to be borland will never going
to address this problem.
You have the problem in version 6 or version 7? And with the RTL update
packs installed? Have either of you checked QualityCentral to see
whether the problem you're experiencing has been addressed? QC#5115
looks promising.
--
Rob
|
|
|
| Back to top |
|
|
Rob Kennedy
Guest
|
| Posted: Sun Nov 23, 2003 9:11 pm Post subject: Re: TMultiReadExclusiveWriteSynchronizer implementation sti |
|
|
Starmen wrote:
| Quote: | However, I have no way of telling whether there is still a lock or
not because no such variable like 'WriteLocks' exists.
|
I don't think you're supposed to be holding on to the locks long enough
to need such a check.
| Quote: | I know that theoretically there can't be any locks left behind if I
use the try... finally.. construction properly, but I want to make
absolutely sure that no thread will ever lock up the entire system
for any reason...
|
If you're using try-finally properly, then there is no need to check
anything else. If it happens that you acquire the lock and somehow jump
over the finally section, a leaked lock is not the worst of your
problems; you either have a faulty compiler or a faulty CPU, and no
amount of checking in the destructor will be able to save you.
--
Rob
|
|
| Back to top |
|
|
Starmen
Guest
|
| Posted: Sun Nov 23, 2003 9:41 pm Post subject: Re: TMultiReadExclusiveWriteSynchronizer implementation sti |
|
|
How about this situation :
- The thread is started
- The thread locks up and does not have the ability to check the
'Terminated' property anymore to do a graceful exit
I have had this happen due to a blocking call in one of the Indy clients
when something went wrong with the communication.
In this case I have no other choice then to use the API call
'TerminateThread' and release the handle.
depending on where the thread locked up, there can be either a lock or not.
In the clean up code after the TerminateThread any locks that are still
there need to be released, but there is no way to tell wether there are
any...
Starmen
"Rob Kennedy" <.> wrote
| Quote: | Starmen wrote:
However, I have no way of telling whether there is still a lock or
not because no such variable like 'WriteLocks' exists.
I don't think you're supposed to be holding on to the locks long enough
to need such a check.
I know that theoretically there can't be any locks left behind if I
use the try... finally.. construction properly, but I want to make
absolutely sure that no thread will ever lock up the entire system
for any reason...
If you're using try-finally properly, then there is no need to check
anything else. If it happens that you acquire the lock and somehow jump
over the finally section, a leaked lock is not the worst of your
problems; you either have a faulty compiler or a faulty CPU, and no
amount of checking in the destructor will be able to save you.
--
Rob
|
|
|
| Back to top |
|
|
David Reeve
Guest
|
| Posted: Mon Nov 24, 2003 7:46 am Post subject: Re: TMultiReadExclusiveWriteSynchronizer implementation sti |
|
|
"Starmen" <someone (AT) microsoft (DOT) com> wrote
| Quote: | How about this situation :
- The thread is started
- The thread locks up and does not have the ability to check the
'Terminated' property anymore to do a graceful exit
I have had this happen due to a blocking call in one of the Indy clients
when something went wrong with the communication.
In this case I have no other choice then to use the API call
'TerminateThread' and release the handle.
depending on where the thread locked up, there can be either a lock or
not.
In the clean up code after the TerminateThread any locks that are still
there need to be released, but there is no way to tell wether there are
any...
|
Seems to me if you bail-out through TerminateThread, you have little hope of
proceding in a determinate manner. OK, the thread object will become
signalled so will release other threads waiting on it, but two points raised
by W32 help worry me....
<W32Help>
· If the target thread owns a critical section, the critical section will
not be released.
· If the target thread is executing certain kernel32 calls when it is
terminated, the kernel32 state for the thread's process could be
inconsistent. </W32help>
As I read the source, the TMultiReadExclusiveWriteSynchronizer uses
Critical sections for locking plus an event object for synchronisation. How
does this sit with the above? To be honest I haven't thought it through, but
it would seem that the state of objects touched by the thread are going to
be indeterminate.
Dave
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
