Overload list. Name, Description. Public function Static. Int8 InterlockedIncrement. ( volatile int8. Value ).

'Joe Cerruto' schrieb im Newsbeitragnews:lntd8.54771$p5.8587301@news1.rdc1.nj.home.com. Am reading Don Box's ATL article on MSDN and Rogerson's Inside COM. Bothsay to use InterlockedIncrement to protect the COM object's reference counterin a multithreading environment. My problem with this is that I thought that incrementing and integer wasan atomic operation anyway. So where is the potential for corrupting this variable?Incrementing a 32 bit value is atomic (at least on 80386 and later, AFAIK),but incrementing and returning the value is not.MatthiasJoe Cerruto22.02.02 8:17.

'Matthias Meyer' wrote in message news:a55p07$4tn71$1@ID-114817.news.dfncis.de.There is no guarantee that incrementing a 32-bit value cannot be interruptedby another thread. Most compiled code would probably generate suchcode, but there is really no guarantee from C or C which you seem tobe using.

'Joe Cerruto' wrote in messagenews:Zuud8.54780$p5.8599966@news1.rdc1.nj.home.com. Thanks for the insight Svante. I think part of my problem in understanding this was not realising that the result of InterlockedIncrement was on the stack and therefore protected from modification while it is being returned from AddRef.If you look at your original example, the data that InterlockedIncrementworks on aren't on the stack (I assume mdwRef is a member variable). Thedifference is that InterlockedIncrement(&mdwRef) is guaranteed (at theassembly code level) to be atomic, whereas mdwRef isn't.-Tim RobinsonJoe Cerruto22.02.02 9:11. In article,says.

My problem with this is that I thought that incrementing and integer was an atomic operation anyway. So where is the potential for corrupting this variable?Incrementing an integer is not necessarily atomic.

A dword willnormally be at least dword aligned, but that's not necessarily thecase. When/if it's not, even just reading a dword isn'tnecessarily atomic - on a 386 or 486, if it starts at an oddaddress, it'll be read as single byte, then two words, then the finalbyte, as three separate bus transactions. If it starts at an addressthat's even but not a multiple of four, it'll be read as twosuccessive words.The Pentium has a substantially different external bus protocol, butthe long and short of it is that if the variable is at the wrongaddress, reading it might still take place in a couple of separatebus transactions, rather than being done atomically.-Later,Jerry.The Universe is a figment of its own imagination.Jerry Coffin22.02.02 18:43. Josh wrote:OK, now what prevents someone else to do AddRef in 1,2,3, or 4 (oranywhere in between, as this is C rather than assembly)?

Suppose someonedoes, but if the count was 0 the object will be deleted!Effectively you're saying:What if someone releases their.LAST. pointer to an object, but then triesto get hold of a pointer to it again?They're not allowed to. There's nothing in C which prevents them doing it(just as there's nothing in C which prevents you freeing a block ofmemory and then accessing it).In a language where COM references are more tightly integrated into thelanguage, I suppose what you ask would be technically impossible. (e.g.the language calls Release precisely when the variable goes out ofscope).-Lucian Wischik, Queens' College, Cambridge CB3 9ET.Tim Robinson23.02.02 5:33. 'Lucian Wischik' wrote in messagenews:a57u48$93t$1@pegasus.csx.cam.ac.uk.

OK, now what prevents someone else to do AddRef in 1,2,3, or 4 (or anywhere in between, as this is C rather than assembly)? Suppose someone does, but if the count was 0 the object will be deleted! Effectively you're saying: What if someone releases their.LAST.

pointer to an object, but then tries to get hold of a pointer to it again?I think this situation is,What if someone releases their.LAST. pointer to an object, at the same timeas someone else tries to AddRef the same object?Answer: I don't personally know.-Tim Robinsonjosh23.02.02 8:21.

On 23 Feb 2002 11:23:52 GMT, (Lucian Wischik) wrote: josh wrote: OK, now what prevents someone else to do AddRef in 1,2,3, or 4 (or anywhere in between, as this is C rather than assembly)? Suppose someone does, but if the count was 0 the object will be deleted! Effectively you're saying: What if someone releases their.LAST. pointer to an object, but then tries to get hold of a pointer to it again?No, I'm saying what if it's done from two different threads. They're not allowed to.Oh, OK.Bob23.02.02 22:23. 'Bob' wrote in messagenews:61e6f8e6.6505c7e0@posting.google.com.

Let's say in your scenario that thread 1 calls Release, and thread 2 calls AddRef while thread 1 is still in Release. If thread 2 has a pointer to the object, then the refcount won't be 0. If thread 2 does not have a pointer to the object, then how does it call AddRef?I just realised that this problem can't (or shouldn't) occur.If two threads each have their own copy of an object then the referencecount will be at least two. Therefore the object will only be freed aftereach thread has called Release. So this situation is illegal: it would beillegal to call AddRef while Release is freeing the object, because thatimplies that the thread calling AddRef is doing so after it has calledRelease. It would mean that there was an unbalanced AddRef/Releasepair somewhere.-Tim RobinsonLucian Wischik24.02.02 7:05.

Crossword quiz social answers. Tim Robinson wrote:It would mean that there was an unbalanced AddRef/Release pairsomewhere.Strictly speaking. They might be fully balanced, but not fully.nested.e.g.Thread1 Thread2x = CreateObject;x-AddRef; x = ReceiveFromThread;PostMessageToThread(x); x-AddRef;Release; x-Release;Here they're both nested.

But the problem that we've been discussing stillarises, because the protocol for how you treat references has not beenrespected.-Lucian Wischik, Queens' College, Cambridge CB3 9ET.Joe Cerruto25.02.02 14:03. In article,says.

I still think that would be OK in this case because another thread cannot change it, whether it is on the stack or in a register. Am I right?Yes - when a context switch is done (whether between processes,threads or fibers) the registers are preserved across the switch.

Infact, registers are more protected from other threads than thestack is. All threads have access to the memory for other threads'stacks but simply don't know where in memory they are. It's muchmore difficult to get access to a thread's register values -possible via GetThreadContext and SetThreadContext, but definitelynon-trivial.-Later,Jerry.The Universe is a figment of its own imagination.josh25.02.02 12:15.