Thread: Conceptual notion of a function/procedure which continuously repeats its methods

Originally Posted by wiqxlzxsxj

I thus far have been putting the repeating functions in a while(true) loop. However for some reason (I may or may not be wrong) it's my understanding that this is frowned upon.

Nothing to frown about. An application main execution loop (aka main loop, aka main event loop) is one of the most common strategies in software development and is an essential design in many types of applications.

A while(true) loop is perfectly valid indicator of a limitless loop whose exit conditions are defined inside. It has an especially powerful semantic value when it wishes to indicate that the loop is in fact meant to be endless until the exit conditions are met. While (true) constructs are to be frown only when they do not convey the meaning of an endless loop. That is, loops that have a clear limit of iterations. Consider the following logic:

Code:

// A
while (true) {
    draw_menu;
    wait_for_input;
    if (input == 'q') break;
    process_input;
    clear_screen;
}

// B
while (true) {
    read_list_node;
    process_node;
    move_to_next_node;
    if (node == NULL) break;
}

Despite both loops having exit conditions (as they should), loop A is being better described. It is meant to be endless, unless a specific condition terminates it. One could say the while (true) construct is a valid semantic. There is no limit imposition to the number of cycles. There are only exit conditions.

Loop B on the other hand is being poorly described. It is not meant to be an endless loop. It has a limit which is the size of the list. And that limit is at least one of exit conditions.

Naturally you can turn limitless loops like A into having the exit condition on the loop declaration. But you aren't required, and your code will under many circumstances become poorer in semantics, because you are removing a powerful indicator of the true meaning of the loop. Whereas loop B does need to be changed for the exact same reason that in its present state it is not representing its true meaning.

while (true) loops are frowned upon because of B loops. Most of the time your loops are of the B type and these type of loops shouldn't be expressed as endless loops. Not only that is a false depiction of their nature, but exit conditions buried inside the loop body may make it harder to understand.

Thanks for this description Mario. i appreciate the effort in clarifying the identity of a loop.

OK.. so considering a while(1) loop, I've inserted a series of functions inside the loop so that the same procedures keep repeating themselves. Can I implement this more effectively using a callback function like so:

Code:

static void manifest_callback(struct *ptr)
{
    function1(ptr);
    function2(ptr);
    .
    .
    .
}

void manifest(struct *ptr, void (*callback)(struct *ptr))
{
    while(1)
    {
        callback(ptr);
        
        if(exit cond) break;
    }
}

void *thread_func(void *PTR)
{
    struct *ptr = PTR;
 
    manifest(ptr, manifest_callback);

         return NULL;
}

The only issue is that CPU usage still goes to > 300%.

You say there are no user events, but what is the program doing?

If your program is processing data from some external source (network, file), then you should be doing something like this

Code:

if ( waitForData() ) {
  // read data and process
}

Not this

Code:

if ( pollForData() ) {
  // read data and process
} else {
  sleep(tick);
}

In Unix/Linux systems, almost all the data a program can receive is obtained via file descriptors. If you're reading file descriptors in your program, then the waitForData() function is called select().



Unless your program is doing something computational (like prime factorisation), you shouldn't be going round in infinite loops repeatedly polling to see if there is more data to process, then throwing in a scattering of 'voodoo' to try and regulate excessive CPU usage.

Yoou're right, this is probably what I need. There is no other way but to use a timeout up to some condition of a file descriptor. I also tried using a semaphore but it would seem one way or another a delay in the loop has to be used.

Using a FD, I have now constructed the following statements. Although I'm not clear if the logic entirely correct.

Code:

quit = false;

/* FD */
fd_set fdset;
struct timeval timeout;

while(!quit)
{
    repeating_function();
        
    if(!quit)
    {
        FD_ZERO(&fdset);
            
        if(var_changes)
            FD_SET(0, &fdset);
        
        else
        {
            timeout.tv_sec = 1 / 10;
            timeout.tv_usec = 100;
              
            select(1, &fdset, NULL, NULL, &timeout);
        }
    }
}

I want to monitor var and if it chhanges only then I wish to call the repeating function.

> FD_SET(0, &fdset);
I thought you said your program had no user interaction?

> I want to monitor var and if it chhanges only then I wish to call the repeating function.
OK, and what changes var in the first place?

Mutexes and condition variables are how threads signal one another.

Though to be honest, I rather suspect you've over-complicated the whole thing by attempting to "solve" some imagined problem by adding threads in the first place.

Originally Posted by wiqxlzxsxj

This could be done in one thread alone whereby the data is fetched, processed, and displayed sequentially. However due to the flexibility of the problem I decided to use multiple threads so that all three processes can run at the same time. This makes good use of available hardware resources and at the same time adheres to the design philosophy.

The operations are entirely sequential. You need the data before you can process it and you need to process it before you can output it. There's no benefit in multi-threading here, particularly because the initial operation of fetching the data from the internet has higher latency than the two other threads combined.

I agree with MutanJohn, seems like program should be event driven. You could use message queues similar to how Windows apps work, where each thread has a input queue that it waits for to become non-empty. Each thread would wait for and retrieve one message from it's input queue, process the message, and then enqueue the message to the next threads input queue. The "last" thread in the chain would enqueue the message to a free pool for that the "first" thread retrieves messages from. I/O driven threads would also wait for I/O's to complete (sequence, get a message, perform I/O, send the message to next thread).

One issue is what to do if the display thread is not keeping up with the data collection thread. Assuming the display thread is the "last" thread, it could monitor the free pool and if the number of messages in the free pool dropped below some threshold, it would start skipping display outputs to catch back up.

This messaging interface is how I've implemented data collection programs, and also how most of the embedded multi-threaded applications I've seen are implemented.