I am working on a problem where I need to pass a message from one thread to other, for example I have 3 threads one for each player, each player has to send 2 messages to other players. Other players also need give their acceptance or rejection based on message they receive.

Please advice which IPC is better for this scenario?

Are we talking about processes or threads?

1 members found this post helpful.

I am planning to use threads

You need to define some parameters. Does each player have a thread that is blocking on the message queue? Are the messages to be kept "secret" from other players? Are messages contemporaneous or is a mailbox adequate (read and respond at some interval)?

It's possible you don't need IPC - since it is internal to a signal thread, managing data structures might work just as well.

Just use globals. Protect them with mutexes when threads are writing to them.

BTW, "IPC" is between processes, not threads. You might want to look up what it stands for.

You can use any or all of the IPC mechanisms you want. I submit that it really depends what message you need to convey. For instance if it is related to the processes or threads, you can use a signal. You can use a pipe, you can use sockets, both of those will convey greater information than singular information. You also can use memory protected by a mutex, as stated earlier in the replies.

There may be a "best" for your situation, but you'll need to determine which of these conveyances works best for your program architecture.

I've recently tried a multi-threaded process where messages are forwarded on pipes (pipe(2)), and a message is always an address of the actual data-area.

Every player should have a way to send & receiver message, as soon as the message arrives player should pick up, each player is unware of other players, but, should have a way to send/receive message.

I guess, I would prefer sockets, because currently I am working on a standalone game , but later it might be an online game.

correct me if I am wrong.., there is no other IPC which communicates through network other than sockets right?
so better use sockets only even if it is a standalone, so that we can improve latter point of for online?

There has been other interfaces other then sockets but Berkley (POSIX) Sockets has supplanted them.

You should at least abstract your communication modules so they can be easily swapped out if you want to try something other then sockets. There are a variety of flavors and options to consider so even if you use sockets abstracting your communication methods is a good idea.

I wouldn't suggest using threads that run on different computers. Actually, they shouldn't called 'threads' to begin with.

If we're talking about multiple executable programs, then I'm not sure if you're using the word "threads" correctly.

1 members found this post helpful.

If we're talking about multiple executable programs, then I'm not sure if you're using the word "threads" correctly.

1 members found this post helpful.

So I think the question basically is client-server vs peer-to-peer networking.

Agreed on all points.

While it seems subtle, I think it would be beneficial to recognize the difference here and that IPC, to me, is defined as InterProcess Communications. Sockets is available, but that really means "local sockets".

And I do feel you have an answer for this question.

Thanks, This is a good suggestion

Use the network, TCP or UDP sockets.

It will work locally or distributed.
It will scale from a desktop PC to the entire universe.