My C program has two threads, both of which interact with two external interfaces. There's too much code for one source file, so I'm splitting it in two. What is the right split?
One thread, MtoD, takes a message off an IPC message queue, processes it, and then sends commands to the driver of a physical interface. The other thread, DtoM, receives interrupts from that driver, processes the input, and then posts the results in a message to an IPC queue.
The obvious ways to split the code in two are:
by thread: two source files, MtoD.c and DtoM.c, each holding all the functions of a single thread - but both files will have to deal with both of the interfaces
by interface: two source files, M.c and D.c, each doing all the business related to a certain external interface - but the threads run through both files.
My concerns are
code maintenance. Doing it by thread makes it easier to follow the logic of a thread (no switching between files). But someone who'd write this object-oriented would probably wrap the interface to the IPC queues in one class, which would be in one file, and the driver interface in another, in the other file.
performance. If you have object files M.o and D.o, each will have just one external library to deal with - but they have to call into each other during execution of a thread. Does that incur any overhead (if the linker has made them into one binary)? If you have MtoD.o and DtoM.o, you could declare most functions as static, which might enable some more compiler optimizations. But would they both need links with the external libraries?
Which way is optimal?
That's an interesting one and you probably get BOTH options being recommended, simply because both have advanteges and disadvantages and it much depends how one values these.
Ok, third option: one thread ? If I get you right you connect a interface to an IPC, so if one thread both reacts to input on either side and sends it out the other side ? I dont think you loose much responce time this way, if any and you have it all in one place. If source is too big you can look into which classes you may naturally separate rather than separating into threads or interfaces.
Related
Suppose I have three C modules:
The first one's function is to generate random output from /dev/urandom and it can work fine independently without other two modules.
The second one's function is to take some forms of input and output some kinds of useful information and it can work fine alone, too.
The last one's function is to manage the former two modules, and connect them, control them through stdout and stdin.
Modules need to communicate through streams under the control of the third module.
Is that a possible scenario? I found that many examples on the Internet just define a function outside a C source file and call it in the main function. That's too weak a relationship. I just wonder if my above scenario is possible. If possible, what kinds of knowledge does it need?
Is that a possible scenario?
Yes. Consider the fact that you can type commands like: cat /dev/urandom | hexdump, which does exactly what you describe where cat is one of your 'modules' and hexdump is the other. In this scenario the shell itself is your third module, starting the other two executables and tying their io together.
I just wonder if my above scenario is possible. If possible, what kinds of knowledge does it need?
You could to read up on the APIs for starting up processes and in particular how to configure their standard IO streams.
On Linux for example the usual way of doing this is using fork() to create a process, execv() to load up your 'modules', pipe() to create the connections between processes, and dup2() to put those connections into the right (stdio) locations.
Here's an example.
I found that many examples on the Internet is just defining a function outside a C source file and call it in the main function. That's too weak relationship.
Not that this is relevant, but I'd actually call that a stronger relationship than what you're talking about. This uses the system linker to tie the two bits of code together. About the only tighter binding would be if you didn't use functions and just wrote the code all together.
Say I have multiple threads and all threads call the same function at approximately the same time.
Is there a calling convention which would only allow one instance of the function at any time? What I mean is that the function called by the second thread would only start after the function called by the first thread had returned.
Or are these calling conventions compiler specific? I don't have a whole lot of experience using them.
(Skip to the bottom if you don't care about the threading mumbo-jumbo)
As mentioned before, this is not a "calling convention" but a general problem of computing: concurrency. And the particular case where two or more threads can enter a shared zone at a time, and have a different outcome, is called a race condition (and also extends to/from electronics, and other areas).
The hard thing about threading is that computing is such a deterministic affair, but when threading gets involved, it adds a degree of uncertainty, which vary per platform/OS.
A one-thread affair would guarantee that it can do all tasks in the same order, always, but when you got multiple threads, and the order depends on how fast they can complete a task, shared other applications wanting to use the CPU, then the underlying hardware affects the results.
There's not much of a "sure fire way to do threading", as there's techniques, tools and libraries to deal with individual cases.
Locking in
The most well known technique is using semaphores (or locks), and the most well known semaphore is the mutex one, which only allows one thread at a time to access a shared space, by having a sort of "flag" that is raised once a thread has entered.
if (locked == NO)
{
locked = YES;
// Do ya' thing
locked = NO;
}
The code above, although it looks like it could work, it would not guarantee against cases where both threads pass the if () and then set the variable (which threads can easily do). So there's hardware support for this kind of operation, that guarantees that only one thread can execute it: The testAndSet operation, that checks and then, if available, sets the variable. (Here's the x86 instruction from the instruction set)
On the same vein of locks and semaphores, there's also the read-write lock, that allows multiple readers and one writer, specially useful for things with low volatility. And there's many other variations, some that limit an X amount of threads and whatnot.
But overall, locks are lame, since they are basically forcing serialisation of multi-threading, where threads actually need to get stuck trying to get a lock (or just testing it and leaving). Kinda defeats the purpose of having multiple threads, doesn't it?
The best solution in terms of threading, is to minimise the amount of shared space that threads need to use, possibly, elmininating it completely. Maybe use rwlocks when volatility is low, try to have "try and leave" kind of threads, that check if the lock is up, and then go away if it isn't, etc.
As my OS teacher once said (in Zen-like fashion): "The best kind of locking is the one you can avoid".
Thread Pools
Now, threading is hard, no way around it, that's why there are patterns to deal with such kind of problems, and the Thread Pool Pattern is a popular one, at least in iOS since the introduction of Grand Central Dispatch (GCD).
Instead of having a bunch of threads running amok and getting enqueued all over the place, let's have a set of threads, waiting for tasks in a "pool", and having queues of things to do, ideally, tasks that shouldn't overlap each other.
Now, the thread pattern doesn't solve the problems discussed before, but it changes the paradigm to make it easier to deal with, mentally. Instead of having to think about "threads that need to execute such and such", you just switch the focus to "tasks that need to be executed" and the matter of which thread is doing it, becomes irrelevant.
Again, pools won't solve all your problems, but it will make them easier to understand. And easier to understand may lead to better solutions.
All the theoretical things above mentioned are implemented already, at POSIX level (semaphore.h, pthreads.h, etc. pthreads has a very nice of r/w locking functions), try reading about them.
(Edit: I thought this thread was about Obj-C, not plain C, edited out all the Foundation and GCD stuff)
Calling convention defines how stack & registers are used to implement function calls. Because each thread has its own stack & registers, synchronising threads and calling convention are separate things.
To prevent multiple threads from executing the same code at the same time, you need a mutex. In your example of a function, you'd typically put the mutex lock and unlock inside the function's code, around the statements you don't want your threads to be executing at the same time.
In general terms: Plain code, including function calls, does not know about threads, the operating system does. By using a mutex you tap into the system that manages the running of threads. More details are just a Google search away.
Note that C11, the new C standard revision, does include multi-threading support. But this does not change the general concept; it simply means that you can use C library functions instead of operating system specific ones.
I'm trying to write an application that connects to multiple IPs/ports and the problem I'm having is that the number of IPs is unknown to me, so one department can use it connect to 2 ips and other department may connect to 8, so it has to be configurable during runtime, I'm thinking of using threads or fork inside loop but not sure which one is better for the job, hope some one can guide me here, I'm using C under Linux.
For example
one can run it like this a.out ip1 port1 ip2 port2 ip3 port3
and the other can run it like this a.out a.out ip1 port1
Thanks
I see four design choices here, each with advantages and disadvantages. Your choice will largely depend on what exactly your application does.
1 process / socket (fork): This has the advantage that a fatal error in one process (e.g., SEGFAULT) will not affect other processes. Disadvantages include the fact that the approach is more resource hungry and that processes are more difficult to coordinate (e.g., if you want to do dynamic load balancing).
1 thread / socket (pthreads): This has the advantage that it is pretty light and threads are easy to coordinate, since they share a common memory space. Disadvantages include the fact that an error in one thread may take your whole application down.
Finite-State Machine: You could use a single thread in a single process, that does a huge poll on all your sockets, then takes the right (non-blocking) action, i.e., read, write or close. I heard this is very fast on a single processor, however, it does not take advantage of multi-core architecture and is somewhat more difficult to program.
Hybrid: pick any of the three above and combine them. See for example the Apache server.
I have a C program that currently uses multiple threads to process data. I use a glib GAsyncQueue for the producer threads to send their data to consumer threads. Now I need to move the threads into into independent processes and I'm not sure how to proceed with pushing data between them. Using pipes does not seem to be very suitable to my task since the amount data being pushed is rather large. Another option is to obtain a piece of shared memory but, since calculating an upper bound on the amount of shared data is a little difficult, this option is less than attractive.
Do you know of something like GAsyncQueue that can be used with multiple processes? Since I'm already using glib, I prefer to use its facilities, but I'm open to using other libraries if they provide what I need.
POSIX specifies a msgsnd(2), msgget(2) interface, though the message and queue sizes may be smaller than you wish. (Linux allows you to modify the sizes with the /proc/sys/kernel/msgmax and /proc/sys/kernel/msgmnb tunable files; the defaults are 8k and 16k.)
Since message buses are a fairly common need you may wish to pick something like RabbitMQ, which provides prewritten bindings to many languages and may make future development easier.
How can I do dataflow (pipes and filters, stream processing, flow based) in C? And not with UNIX pipes.
I recently came across stream.py.
Streams are iterables with a pipelining mechanism to enable data-flow programming and easy parallelization.
The idea is to take the output of a function that turns an iterable into another iterable and plug that as the input of another such function. While you can already do this using function composition, this package provides an elegant notation for it by overloading the >> operator.
I would like to duplicate a simple version of this kind of functionality in C. I particularly like the overloading of the >> operator to avoid function composition mess. Wikipedia points to this hint from a Usenet post in 1990.
Why C? Because I would like to be able to do this on microcontrollers and in C extensions for other high level languages (Max, Pd*, Python).
* (ironic given that Max and Pd were written, in C, specifically for this purpose – I'm looking for something barebones)
I know, that it's not a good answer, but you should make your own simple dataflow framework.
I've written a prototype DF server (together with a friend of mine), which have several unimplemented features yet: it can only pass Integer and Trigger data in messages, and it does not supports paralellism. I've just skipped this work: the components' producer ports have a list of function pointers to consumer ports, which are set up upon the initialization, and they call it (if the list is not empty). So, when an event fires, the components perform a tree-like walk-thru of the dataflow graph. As they work with Integers and Triggers, it's extremly quick.
Also, I've written a strange component, which have one consumer and one producer port, it just simply passes the data thru - but in another thread. It's consumer routine finishes quickly, as it just puts the data and sets a flag to the producer-side thread. Dirty, but it suits my needs: it detaches long processes of the tree-walk.
So, as you may recognized, it's a low-traffic asynchronous system for quick tasks, where the graph size does not matter.
Unfortunatelly, your problem differs as many points from mine, just as many one dataflow system can differ from another, you need a synchronous, paralell, stream handling solution.
I think, the biggest issue in a DF server is the dispatcher. Concurrency, collision, threads, priority... as I said, I've just skipped the problem, not solved. You should skip it, too. And you also should skip other problems.
Dispatcher
In case of a synchronous DF architecture, all the components must run once per cycle, except special cases. They have a simple precondition: is the input data available? So, you should just to scan thru the components, and pass them to a free caller thread, if data is available. After processing all of them, you will have N remaining components, which haven't processed. You should process the list again. After the second processing you will have M remainings. If N == M, the cycle is over.
I think some kind of same stuff will work, if the number of components is below only 100.
Binding
Yep, the best way of binding is the visual programming. Until finishing the editor, config-like code should used insetad, something like:
// disclaimer: not actual code
Component* c1 = new AddComponent();
Component* c2 = new PrintComponent();
c2->format = "The result is %d\n";
bind(c1->result,c2->feed);
It's easy to write, well-readable, other wish?
Message
You should pass pure raw packets among components' ports. You need only a list of bindings, which contain pairs of pointers of producer and consumer ports, and contains the processed flag, which the "dispatcher" uses.
Calling issue
The problem is that producer should not call the consumer port, but the component; all component (class) variables and firings are in the component. So, the producer should call the component's common entry point directly, passing the consumer's ID to it, or it should call the port, which should call any method of the component which it belongs.
So, if you can live with some restrictions, I say, go ahead, and write your lite framework. It's a good task, but writing small components and see, how smart can they wired together building a great app is the ultimate fun.
If you have further questions, feel free to ask, I often scan the "dataflow" keyword here.
Possibly, you can figure out a more simple dataflowish model for your program.
I'm not aware of any library for such purpose. Friend of mine implemented something similar in versity as a lab assignment. Main problems of such systems is low performance (really bad if functions in long pipe-lines are smallish) and potential need to implement scheduling (detecting dead-locks and boosting priority to avoid overload of pipe buffer).
From my experience with similar data processing, error handling is quite burdensome. Since functions in the pipeline know little of the context (intentionally, for reusability) they can't produce sensible error message. One can implement in-line error handling - passing errors down the pipe as data - but that would require special handling all over the place, especially on the output as it is not possible with streams to correlate to what input the error corresponds.
Considering known performance problems of the approach, it is hard for me to imagine how that would fit microcontrollers. Performance-wise, nothing beats a plain function: one can create a function for every path through the data pipe-line.
Probably you can look for some Petri net implementation (simulator or code generator), as they are one of the theoretical base for streams.
This is cool: http://code.google.com/p/libconcurrency/
A lightweight concurrency library for C, featuring symmetric coroutines as the main control flow abstraction. The library is similar to State Threads, but using coroutines instead of green threads. This simplifies inter-procedural calls and largely eliminates the need for mutexes and semaphores for signaling.
Eventually, coroutine calls will also be able to safely migrate between kernel threads, so the achievable scalability is consequently much higher than State Threads, which is purposely single-threaded.
This library was inspired by Douglas W. Jones' "minimal user-level thread package". The pseudo-platform-neutral probing algorithm on the svn trunk is derived from his code.
There is also a safer, more portable coroutine implementation based on stack copying, which was inspired by sigfpe's page on portable continuations in C. Copying is more portable and flexible than stack switching, and making copying competitive with switching is being researched.