Board index » cppbuilder » Has anyone used TMultiReadExclusiveWriteSynchronizer?

Has anyone used TMultiReadExclusiveWriteSynchronizer?


2005-01-28 07:03:45 AM
cppbuilder90
I am writing a DLL that uses a thread to do socket communications with an
automation controller. There is only one DLL, and one thread. Everything
is working fine, but I am trying to add a user abort function. Basically I
have a variable in the thread called UserAbort. The functions that do the
communications check the state of this variable frequently to see if they
should abort. The thread reads the variable frequently, but only writes to
it in the constructor, and after it has performed the user abort to reset it
to false. I was trying to decide the best way to set this variable from the
DLL, and was considering TMultiReadExclusiveWriteSynchronizer?
Any suggestions?
Pseudo code fragment:
Thread:
while (!Done && !UserAbort)
WorkVeryHard;
if (UserAbort)
UserAbort = false; // reset
DLL:
void SendUserAbort(void)
{
if ((MyThread != NULL) && (!MyThread->Suspended)) // must exist and be
busy
{
MyThread->UserAbort = true;
}
}
(No one panic...) Do you think I could even get away without locking at all?
 
 

Re:Has anyone used TMultiReadExclusiveWriteSynchronizer?

"Fred Hebert" < XXXX@XXXXX.COM >wrote in message
Quote
I was trying to decide the best way to set this variable from the
DLL, and was considering TMultiReadExclusiveWriteSynchronizer?
Since the variable in question is just a simple flag, the Interlocked
functions would have much less overhead then a TMREWSynch. Actually, for a
boolean value, you wouldn't even need the Interlocked functions, either,
since a bool is only 1 bytes in size and thus access would be atomic anyway
(unless you have multiple CPUs accessing the threa, that is, in which case
do use synchronization).
Quote
Pseudo code fragment:
Without seeing what else the Thread actually does (is the code block you
showed being called in a while(!Terminated) loop?), given the code you did
show, you don't really need to sync access to UserAbort at all. Just set it
to false before starting the work and then leave it alone until the next
time the work begins. If the user calls SendUserAbort() during current
work, UserAbort gets set. If the user calls SendUserAbort() when no work is
going on, it won't have any affect since the code would reset UserAbort
during the next work anyway. In fact, you could just use the Terminated
property flag and get rid of UserAbort altogether. But, it is hard to say
for sure since you did not show enough code to see what you are actually
doing.
Gambit
 

Re:Has anyone used TMultiReadExclusiveWriteSynchronizer?

"Fred Hebert" < XXXX@XXXXX.COM >wrote in
Quote
...
I was trying to decide the best way to set this variable from the DLL,
and was considering TMultiReadExclusiveWriteSynchronizer?
Don't use TMultiReadExclusiveWriteSynchronizer
Check QC 5115, 4687, 4685 and 4654
--
Peter Strömberg (55.6N 13.0E)
C2K2 C2K3 ISCCIV02 ISCCIV03 ISCCIV04
 

{smallsort}