Interlocked fcns.

[fluppe]

Hi, i have a question that was hard for me to figure out so far:

is the "orig = InterlockedExchange(dest, val)" fcn. blocking, as long as any other thread tries to manipulate the value behind "dest" ?

Maybe a link to a resource where i can find thte answer to my tiny question ?
I have looked through the MSDN help, but well, ... maybe i am blind (i really consider that to be possible) ... i did not find that statement, or did not understand.

Thanks for taking your time,

...

[coder777]

Read this:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms683590%28v=vs.85%29.aspx

It guarantees that only one thread can manipulate 'dest'. And yes the other threads are waiting for this function to finish if they use InterlockedExchange(...) as well.

[fluppe]

So, that means the threads are stuck within the "InterlockedExchange" fcn ??


I was confused, because i only found examples where something like

...
while(InterlockedExchange(&dest, val) != val){

     sleep(10);

}

was used to keep the thread waiting, which seems superfluent to me, if the function just won't return.
I'll read the link, thanks a lot,

...

[coder777]

if the function just won't return.

The function returns as soon as it is done.

This is basically

InterlockedExchange(&dest, val)
{
  lock(); // Other threads are waiting here

  org_value = *dest;
  *dest = val;

  unlock(); // Other threads are released for modifying dest

  return org_value;
}

This is meant when they state about 'atomic operation'.

[fluppe]

I see, i think i have got it right now. Well, that seems to be most suitable for my needs indeed ... thanks a lot.
Another thing:
If have a class and a mutex guarded portion of code in one of it's methods, then different objects of the same class can not enter that code at the same time, right ?

Or is that not the case if every one of those objects has it's own mutex ?

Maybe that is an own thread anyway ...

Thanks a lot for your help, i read the link, but the explanation above was much more helpful indeed.
Best regards,
....

[coder777]

Or is that not the case if every one of those objects has it's own mutex ?

Exactly. The class is not relevant. The 'physical' object is.

Only if two or more threads are trying to access the same object you need to protect the object. Also the mutex: Only if threads accessing the same mutex the locking mechanism will apply.

[fluppe]

That sounds great. I was trying the interlocked fcns because i thought i could not protect the methods "objectwise" in an appropriate manner. However, maybe i still don't need mutexes or critical sections for now.
Thanks again,
...