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 ?
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...
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.
Related
I need your help to solve this problem.
I have to create a multi-threaded client-server program on unix, based on AF_UNIX
sockets, that must handle up to some thousands simultaneous connections and also must do different things based on the type of signal received, like shutdown when server receives a SIGINT.
I thought of doing this disabling, initially, SIGINT and the other signals from the main's thread sigmask, then starting up a dispatching thread, that keeps (I know that's really inefficient this) waiting on select() for I/0 requests, accepts the new connection and then reads exactly sizeof(request) bytes, where request is a well-known structure, then creating also a thread that handles the signals received, the only one that re-enables the signals, using sigwait(), and finally starting up the other server thread to execute the real work.
I have this questions:
I would like to let select() return even if the dispatcher thread is stuck in it. I've red of a self-pipe trick about this, but I think I made it wrong, because even if I let the signal-handling thread write in the pipe that's in the select's read set, select() won't return. How could I let select() return?
I've read something about epoll(), that's the efficient to handle many simultaneous connections efficiently. Should i, and if how, use it? I can't figure it out only reading man epoll, and on my text book it's not even mentioned.
There are some good practices that I could use for handling system's failures? I almost check every system call's return value to, eventually, handle the error to free memory and other stuff like this, but my code keeps growing a lot, and almost for the same operations repeated many times. How could I write a cleanup function that could free memory before returning with abort()?
Anyway, thanks a lot in advice for your help, this platform is really amazing, and when I'll get more expert, I'll pay the community back giving my help!
(Sorry for my English, but it's not my mother language)
I am learning about threads. And I need to understand how threads communicate between each other, so what does it mean when we say something like "let Thread A send a message to Thread B"?
I can think of the following:
Thread B is blocking on some sort of queue, and Thread A places a new
entry in this queue, which causes Thread B to unblock, and retrieve
this entry.
Thread B is blocking on an event (for example, in Windows API there
is the Event object), and Thread A signals this event which will
cause Thread B to wake up (or is this called notifying a thread and
not sending a message to it?)
The "threads" world is subject of many ambiguity due to different nomenclature coming from different environments, sometimes using same words to mean different things.
Your first assertion makes sense in very general terms: the "message" is what makes the thread to wake-up and get some "input".
Depending on the OS and its own API, your second assertion makes sense and is nothing more then a way to implement the first using the Win32 API.
Another possible interpretation can be that the thread is blocked on a message loop (see GetMessage) and the other one calls PostThreadMessage.
In a more general term, you can think of a "message" as an "event" that carries a "state" with it: an event simply happens (and that's all the information it gives). A message "happens", and has some parameter associated with it.
Link to example Windows code that uses two threads to copy a file, the original thread reads, a created thread writes. There's a custom messaging system that uses Windows mutexes and semaphores. Other than the overhead to create and delete the mutexes and semaphores, the actual functions are fairly small. I've worked on embedded multi-threaded devices, using a similar messaging interface scheme.
http://rcgldr.net/misc/mtcopy.zip
i am writing a small IRC program in C.I'm using thread to handle multiple clients,
and i use a chained list to store the fd of each client.So if a client send a message, it will be written on the fd of the others.
I'm not sure this is the best way to do, could you give me some advice ???
Plus, in this way, i need to share the struct (that contains the file descriptior of each clients) throughout the thread, so if there is an update in a thread, it will update the struc for the others.I'm wondering how i could do this, how could i share that struct ??
Any help is welcome.
Without knowing more about your design it's very difficult to comment on whether your linked list of FDs is appropriate.
In terms of sharing a struct of data between threads there is nothing you need to do. Threads share memory space so anything visible in one thread will be visible in another. Your only risk is that you have multiple threads modifying the struct at one time, something you protect against by using a mutex (mutual exclusion semaphore).
Since you're on Linux I'm assuming you're using POSIX Threads (pthreads) in which case you'll need to look at the pthread_mutex_ functions.
In your setup, I would use:
one input queue per channel,
one output queue per client.
Whenever a client thread receives a message, it posts it to the channel thread. When a channel receives a new post, it reposts it to all the clients. Each channel and client can be represented as a struct, which may be handled then by the threads (with one or more clients or channel per thread).
All queues are simple linked lists protected using a pthread_mutex_t. When a function needs to access them, it locks the queue, add the message, and unlock.
pthread_mutex_create
pthread_mutex_lock
pthread_mutex_unlock
Given a process id, I would like to find how may signals { including real time signals } are delivered, and handled. Is there any way to get from /proc file system?, If so, how to do that ?. Kindly guide.
Referring "pending signals":
One can use sigpending() to get a set of types of signals pending for a given process. This isn't the actual number of signals that had been sent to the process.
Referring "delivered signals":
One can set up a signal handler using sigaction() which in turn can count how often it is called. Anyhow the kernel or the run-time library (I'm not sure which) might decided to only call the handlers once for one or more signals of the same type having been sent close together in time.
An alternative way to collect signals is the use of sigwaitinfo(), probably in a dedicated thread.
This is for an assignment I'm working on, and NO I'm not looking for you to just GIVE me the answer. I just need someone to point me in the right direction, maybe with a line or two of sample code.
I need to figure out how to set the priority of a file read operation from within my program. To the point:
server process receives a message and spawns a child to handle it
child tries to open the filename from the message and starts loading the file contents into the message queue
there may be several children running at the same time, and the initial message contains a priority so some messages may get more device access
The only way I can think to do this (right now, anyways) would be to increment a counter every time I create a message, and to do something like sched_yield after the counter reaches a given value for that process' assigned priority. That's most likely a horrible, horrible approach, but it's all I can think of at the moment. The assignment is more about the message queues than anything else, but we still have to have data transfer priority.
Any help/guidance is appreciated :)
Have the pool of child processes share a semaphore. Once a child acquires the semaphore it can read a predefined number of bytes from the resource and return it to the client. The number of bytes read can be related to the priority of the request. Once the process has read the predefined number of bytes release the semaphore.
Until recently, there was no IO prioritization in Linux. Now there is ionice. But I doubt you are meant to use it in your assignment.
Are you sure your assignment is talking about files and not system V message queues?
Read the man pages for:
msgctl(2), msgget(2), msgrcv(2), msgsnd(2), capabilities(7),
mq_overview(7), svipc(7)
Although I think you can use a file as a key to create a message queue, so that multiple processes have a way to rendezvous via the message queue, a Sys V message queue itself is not a file.
Just wondering because you mention "message queues" specifically, and talk about "priorities", which might conceivably map to the msgtyp field of eg. msgsnd and msgrcv, though it's hard to tell with what information you've given what the assignment really is about.