For the company I work at, all of our projects,
including a new one started last year, are written in C89.
We write for vxWorks (a real time embedded operation system).
Our software runs multi-threaded through various spawned “tasks”

We are massively behind schedule, and I am struggling to be productive based on the company’s design for new software components.

Coming from a C++ background, I’m use to wrapping mutable state inside of a class, and then providing methods as an interface to manipulate the state:

I realize that C doesn’t have these language features, but I’ve always been under the impression that C developers do something similar with a set of global functions and having their “struct” as the first argument to all of these functions.

In both of these cases, we still have an interface. It describes the actions that can be taken on the component, and helps with readability / dealing with mutable state.

I am not allowed to write software components in the way I described above.

Our company design, as I have come to understand it, is as followed:

• Every component must be expressed as a TypeInput, and a TypeOutput.
• Each component will have two global functions associated with it:
  • Initialize (takes and modifies TypeOutput)
  • Update (takes TypeInput, and TypeOutput; modifies TypeOutput)

Here is the smallest example I could find that helps express the idea.
A popable breaker:

typedef struct CircuitBreakerInputs_t
{
    BOOL m_bPopped;

} CircuitBreakerInputsT;

typedef struct CircuitBreakerOutputs_t
{
    BOOL m_bPopped;

} CircuitBreakerOutputsT;

void InitializeCircuitBreaker(CircuitBreakerOutputsT *const ptOutputs)
{
  //initalizes ptOutputs
}

void UpdateCircuitBreaker(CircuitBreakerOutputsT *const ptOutputs, const CircuitBreakerInputsT *const ptInputs)
{
   //observes inputs to modify outputs
}

On the surface, this may seem like a simple and straightforward design.
Inputs become outputs based on the current state of outputs.

Now consider a component with more than one functionality. Let’s take a millisecond timer. It can move forward in time, be paused, be unpaused, and be reset. That would look like this:

typedef struct MillisecondTimerInputs_t
{
    BOOL m_bAdvanceTime;

    BOOL m_bSetPauseState;

    BOOL m_bReset;

    BOOL m_bPause;

} MillisecondTimerInputsT;

typedef struct MillisecondTimerOutputs_t
{
    double m_dElapsedTime_ms;

    BOOL m_bPaused;

    unsigned long m_ulLastUpdateTickAmount;

} MillisecondTimerOutputsT;

void InitializeMillisecondTimer(MillisecondTimerOutputsT *const ptOutputs){
      //initializes ptOutputs
}
void UpdateMillisecondTimer(MillisecondTimerOutputsT *const ptOutputs, const MillisecondTimerInputsT *const ptInputs){
       //observes inputs to modify outputs
}

This gets more complicated to use. Our inputs, are becoming triggers as to how we want to use the component. In order to get the specified functionality out of our component, we need to move the interface into the Update call and rely on the input data to dispatch appropriately.

Of course, this allows you to call more than one hidden method when setting more than one method trigger(a boolean) to true. If the order in which the methods are called matters, you are left to either rely on the implementation, or set each one to triggers separately and call Update for each of them.

You also need to be careful that you aren’t calling any additional methods by accident. For example, when you construct the InputType, you need to set all the triggers to false initially. Then you need to set the trigger you want to call to true, and call update. You then need to potentially set that trigger back to false if you intend on enabling a new trigger for the next update.

To make the process easier, I began using enums to represent the method I want to call. This was more in accordance with the initial design I showed earlier, because only one method can be called based on the enumerated value.

I had to revert back to the booleans through because our design did not permit a third enumerated type for doing this kind of dispatch.

The only way I was able to write concise tests for these components, was by creating a set of utility functions that take the OutputType, forward params into the input struct, and surface the appropriate output as a return value. This gave me back the interface I lost.

I then went on to write a language that allowed me to express code in the same manner as the first diagram. I write code as a stateful object with an API in C++, and it can algorithmically be turned into any of the other diagrams shown thus far. Based on this design I can better construct, and test the code. I generate the input/output C design, and then I generate a C++ wrapper that holds the C OutputType, and provides the interface shown in the diagram above.

My automation breaks down in regards to component composition.
Our company prohibits InputTypes from containing OutputTypes, and vice versa. Which is unfortunate, because the OutputTypes are what have the state. So I can’t easily pass a component into the method of another component. It is inputs, outputs, and updates all the way down. Additionally, you can only call update once for each of the sub components.

Only being able to call Update once on each of the sub-components, has also hurt my productivity. Dealing with component interaction, and component transformation has to be done over the duration of various Updates. There are other routes I have tried to take, but it overcomplicates the Input/Output types.

Are there good merits to this design?
The lead engineer has told me:

however the stateful object above has no specific division of memory
for mutual exclusion. In order to do this, we needed new objects for
memory management and cross thread locks

Is this design better for multithreading? I don’t understand why we couldn’t just make copies, and still use the threading mechanisms appropriate when dealing with shared memory. Additionally, we don’t use any threading in our sub components, and the highest level OutputType, gets copied while performing a semaphore locked read/write. We also don’t use any dynamic memory allocation on the heap, but even if we did, I don’t think this would affect the explanation. We would just need to manage that memory appropriately, when making copies and such.