You have a legitimate concern. But here's the problem in your reasoning:
The reference count is meant to count references. It protects the
object. The reference count does *not* protect the references to that
object. In your scenario, there are two threads that both have access to
the apparently global IntfA variable. If two threads have access to the
same variable, then there are really two references, so the reference
count should be 2, not 1.
The alternative is that you should use a critical section to protect
access to the global variable, so you can have one thread reading it
while another is writing it.
The same goes for global string variables. And these don't necessarily
have to be global variables, either. They can be fields of an object, as
long as multiple thread have access to the same fields at the same time.
--
Rob
I am using interfaces heavily in multi-threaded scenario, which is not
going to be threadsafe (as I suspected and you just explained):
Although the interfaces references are not "global" global, they resides
in a "registry" known by many threads, and threads make (de)references to
the interfaces, as well as perform (un)registering operations.
Problem arises when a thread tries to makes a references to an interface
while another trying to unregister it, if the interface have just one
reference (by the registry).
Since I try to optimize for performance, I will apply a spin lock for each
interface. Although I think a better synchronization model is reader/writer
lock (refcounting is the "read" operation, while unregister is the
"write"),
I think using spinlock wouldn't make too much difference since the refcount
operation is so short...
AdamWu
---
.dlrow eht htiw thgir s'lla ,nevaeh sih ni si doG
_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
