0

threaded programming

I want to write simple multi-thread app.

where each thread when it open I increment (using InterlockedIncrement) member by one , and decrements it (using InterlockedDecrement) when thread finishes

I know about Mutex/Semaphore/event

but I would more clean /simple way to implement comparison similar to the Interlocked function .

What I need next is implement comparison function [if(member == x)]

simple example:

Thread 1 function:

{
//do somthing 
InterlockedDecrement(member);
}

Thread 2 function:

{
//do something else
InterlockedDecrement(member);
}

main thread function :

{
  while(member)//<--how can it be done in thread safe fashion
  {
    //do yet another something
  }
}
David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
LordTitiKaka
  • 2,087
  • 2
  • 31
  • 51
  • 1
    some kind of locking mechanism is all you need, IMHO. – Sourav Ghosh Jan 05 '16 at 08:05
  • look at my edited question :) – LordTitiKaka Jan 05 '16 at 08:07
  • Both threads are decrementing, and you need to pass `&member` presumably. What problem are you actually trying to solve? You want to write a spin lock? – David Heffernan Jan 05 '16 at 08:54
  • @DavidHeffernan i wrote example for the sake of an Example , I want to write server-client and I want that once the server starts , it will exit when all client left , I'm now in the part of exploring my options – LordTitiKaka Jan 05 '16 at 09:00
  • Can you explain *why* you're doing this stuff? It seems odd that you're writing a simple multi-threaded app and you need something very unusual. Perhaps you're approaching a problem the wrong way. – David Schwartz Jan 05 '16 at 09:05
  • This isn't the way to achieve that goal. – David Heffernan Jan 05 '16 at 09:05
  • Reads of 32 bit aligned values are always atomic on Windows. – Jonathan Potter Jan 05 '16 at 09:49
  • @JonathanPotter Atomicity is required, but not sufficient. For example, if the read of `member` is optimized out by the compiler, he's still not going to be happy. – David Schwartz Jan 05 '16 at 10:03
  • @DavidSchwartz I'll put it in volatile . I sorry if I put you out of course but this question was more of a theoretical than practical . I want to design simple server , and the while thing was the first thing that came to my head. I'll revise my design – LordTitiKaka Jan 05 '16 at 10:56
  • Why don't you ask us how to solve your problem. If you would do that you'd learn how to do this properly. Without this nasty loop. – David Heffernan Jan 05 '16 at 11:38
  • @DavidHeffernan thanks for you offer :) I think in SO it is not accepted but if you like i can share with you my code + I'll think how to post proper question – LordTitiKaka Jan 05 '16 at 13:17
  • No, I don't want to see all of your code. But earlier you said "I want to write server-client and I want that once the server starts, it will exit when all client left." If the question contained that info and asked how to do it we could give you message passing or signal based suggestions. Your current approach performs poorly. – David Heffernan Jan 05 '16 at 13:19
  • @DavidHeffernan following your comment I've updated my question and added code to show my parts of my current code – LordTitiKaka Jan 05 '16 at 14:35
  • That should be a new question. Your original question was well posed and has been reasonably answered. Please do accept that answer. – David Heffernan Jan 05 '16 at 14:36
  • 1
    @DavidHeffernan you right , I've accepted the amswer and uploaded another question – LordTitiKaka Jan 05 '16 at 15:11

1 Answers1

2

Use InterlockedAdd and add 0. This will lock the member and return the value without changing it:

while (InterlockedAdd(&member, 0) == someValue) 
{
    //do yet another something
}
Klas Lindbäck
  • 33,105
  • 5
  • 57
  • 82
  • This will implement a busy loop. Perhaps you should advise the asker about the perils of doing that. – David Heffernan Jan 05 '16 at 08:55
  • @DavidHeffernan Wouldn't that depend on what code you insert instead of `//do yet another something`? – Klas Lindbäck Jan 05 '16 at 08:59
  • Well, yes it would. I suppose I was assuming that asker is writing a spin lock. – David Heffernan Jan 05 '16 at 09:01
  • On x86 CPUs, this will perform pretty terribly because it's a needless read-modify-write operation that will result in the cache line being held exclusively by this core. Imagine if two cores are both running this code with any frequency -- for no good reason, they'll be unable to share the cache line and it will ping-pong over and over. (Perhaps performance doesn't matter at all.) – David Schwartz Jan 05 '16 at 10:58
  • @KlasLindbäck sorry but I remove my approval of an answer due to changes in my question – LordTitiKaka Jan 05 '16 at 14:36
  • @LordTitiKaka That's not really fair. Once you've got a clear answer to a clear question it's not on to change the question. I think you should accept this answer. It is the answer to the question that you asked. – David Heffernan Jan 05 '16 at 14:37