5

I am programming with pthread in C language. I want a thread to tell other threads that it has put a message on the message queue, so that other threads would know that they can fetch messages from the message queue. However, the thread which has sent the signal should supply more information to other threads, such as thread id, message tag, and so on. How to do that ?

I know pthread_kill function, but It seems take little information. Can I take more information when I use a thread send signal to other threads ?

DOK
  • 32,337
  • 7
  • 60
  • 92
Nick Dong
  • 3,638
  • 8
  • 47
  • 84
  • 4
    Folks should be a little more understanding about fellow developers whose first language is not English. – DOK Dec 29 '12 at 15:18
  • Tks for your consideration, DOK. – Nick Dong Dec 29 '12 at 15:18
  • Is your real question "how do I make a waitable message queue to pass messages between threads?" If so, signals are *definitely* not the right way. – David Schwartz Dec 29 '12 at 19:59
  • @DavidSchwartz Actually, I dont want the threads which try to receive messages to wait for a long time, even though there is a waitable message queue. – Nick Dong Dec 30 '12 at 17:47

2 Answers2

6

A signal in the C sense is not able to take "more information" - if you want to send more information, then you need to include that as part of the message in the message_queue, rather than as part of the signal.

I'm pretty sure there are dozens of alternatives. Just that you haven't thought of them. Like I said, if you want to use signals, then use a signal to indicate that there is a message (like the telephone ringing) then use a message queue to convey the actual information (talking on the phone). We don't use the phone ring signal to convey the message over the phone, right?

But I fear that you have somehow misunderstood the usage of threads and signals. I'm pretty sure that the way you are SUPPOSED to solve whatever you ar doing, isn't the right way.

Since your question is "How do I send more than an integer in a signal, I think you should accept Arno's answer, and then try again if that doesn't help - with a description of what your OVERALL problem is that you are trying to solve - right now you are talking to a mechanic about how to losen a bolt, but what you really need to do is fix a puncture, so you may be too concentrated on how to solve the detail, to muss the fact that you haven't even got a jack to lift the car off the ground...

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
  • I want the thread which receive message to know that the messages have arrived. so I need the thread which put message to the queue to notice other threads. @Mats Petersson – Nick Dong Dec 29 '12 at 15:24
  • Yes, so you can use a signal to send a message that "there is a message in your message queue". You can't pass more information than that in the signal itself. If by "signal", you don't mean a regular C style signal as defined by then we need to have more clarity in your question. – Mats Petersson Dec 29 '12 at 15:28
  • Yes, I dont know any other methods except kill() and pthread_kill(). – Nick Dong Dec 29 '12 at 15:53
  • Since my response got a bit long, I have edited my answer instead. – Mats Petersson Dec 29 '12 at 19:51
  • 1
    +1 for _"right now you are talking to a mechanic about how to losen a bolt, but what you really need to do is fix a puncture"_. That's so true. @NickDong: Maybe you can explain in some more detail what you're trying to accomplish? – Arno Dec 29 '12 at 20:47
  • yes, In my program, threads would send messages to each other. I let they all share a message queue. so all "message sender" put messages to the queue, and all "message receiver" fetch message from the queue. The queue should be locked using mutex. If the receiver dont know when the message arrived, it will lock the queue frequently for check the queue. Other threads would be wait for a long time, if they do not get the mutex lock, and maybe starved. And a better solution is the "message sender" notice the receiver. @Arno – Nick Dong Dec 30 '12 at 17:28
  • Imagine that there are many(e.g. M) threads send messages to threads T1, and they have sent signals M times to T1 and put messages in the queue. At this time there have been M piece of messages in the queue. T1 only receive one message at once. When T1 try to receive one message from T3, it still dont know whether the message of T3 is in the queue, even though T3 have noticed it. So I think that it should be better to take thread id and message tag of T3 in the signal. @MatsPetersson – Nick Dong Dec 30 '12 at 17:43
  • So, I still think you are trying to solve a problem the wrong way, and as I said, please accept either of the two answers given here, and start over with a question that describes your actual situation that you are trying to solve. Why can't the threads wait for a message? That's the TYPICAL solution for these sort of things - you have queues, you pick off a message in a thread, process it, send back a result [if applicable] and go pick up the next message. If no message available, thread sleeps until one becomes available. – Mats Petersson Dec 31 '12 at 00:27
  • @NickDong: locking a mutex and fetching a message is rather quick. I don't agree that this causes starvation in general. – Arno Dec 31 '12 at 14:31
4

Threads of a process share the same adress space. Thus it is common to build a mutex protected message queue for interthread communication. See this answer to get into the details. The message queue may be a custom design e.g. a linked list structure which may contain elements like sender ThreadID, receiver ThreadID, the message, and optional any number of additional parameters like message state or something. It may also contain a unique message ID and a parameter to tell the receiving thread how to proceed, e.g. remove the message from the queue or not. A signal can still be used to avoid polling the message queue for new messages. A signal will trigger threads to read the mutex protected message queue for new messages. Another way is to build up an event scheme, as described in this answer. But this is in fact also a mutex protected global identifier which is set and the waiting thread is polling for the change (so called busy wait). Could do the busy wait on the mutex protected message queue right away. See this link for more information about pthread_cond_wait.

Community
  • 1
  • 1
Arno
  • 4,994
  • 3
  • 39
  • 63