Understanding the Observer Pattern in C: A Practical Guide for Event-Driven Systems

The Observer pattern stands as one of the most fundamental behavioral design patterns in software engineering. Its core purpose is to establish a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. In C—a language without built-in object-oriented constructs—implementing this pattern requires careful use of function pointers, dynamic data structures, and memory management. When done correctly, the Observer pattern enables you to build highly modular, event-driven systems that scale gracefully with complexity.

This article covers the theoretical foundation of the Observer pattern, a step-by-step implementation in ANSI C, advanced considerations such as thread safety and dynamic observer management, and real-world use cases. By the end, you will be able to design and integrate a clean observer mechanism into your own C projects.

Core Concepts of the Observer Pattern

At its heart, the Observer pattern decouples the subject (the object that holds state) from the observers (objects that need to react to state changes). The subject maintains a list of registered observers and broadcasts notifications to all of them whenever its state changes. Observers can join or leave the list dynamically, without the subject needing to know their concrete types.

The key players in the pattern are:

  • Subject – the observable entity that tracks its observers and fires notifications.
  • Observer – an interface (or abstract protocol) that defines the update method.
  • ConcreteObserver – a specific implementation of the observer interface that responds to events.
  • Client – the code that configures the relationships and triggers changes.

In languages like Java or C++, the pattern is often implemented with abstract classes or interfaces and virtual methods. C lacks these features, so we rely on function pointers and opaque data structures.

Implementing the Observer Pattern in C

Let’s walk through a complete, production-oriented implementation. We’ll create a system that manages multiple listeners for different event types. The design will be generic enough to reuse across projects.

Defining the Observer Interface

In C, the observer interface is a function pointer signature. We need to pass a context pointer so each observer can maintain its own state:

typedef void (*ObserverCallback)(void *context, int event_type, void *event_data);

The context parameter is a void* that allows each observer to store arbitrary data (e.g., a file descriptor, a GUI widget handle, or a linked list of pending events). The event_type identifies which event occurred, and event_data can carry additional payload.

Building the Subject Structure

The subject must hold a dynamic list of observer entries. Each entry contains the context pointer and the callback function:

typedef struct {
    void *context;
    ObserverCallback callback;
} ObserverEntry;

typedef struct {
    ObserverEntry *entries;
    size_t count;
    size_t capacity;
} Subject;

We also need functions to initialize the subject, register observers, unregister observers, and notify all observers.

Initialization and Cleanup

Proper memory management is critical. We allocate the initial array with a reasonable capacity:

void subject_init(Subject *s, size_t initial_capacity) {
    s->entries = malloc(initial_capacity * sizeof(ObserverEntry));
    if (!s->entries) {
        fprintf(stderr, "Observer memory allocation failed\n");
        exit(EXIT_FAILURE);
    }
    s->count = 0;
    s->capacity = initial_capacity;
}

void subject_destroy(Subject *s) {
    free(s->entries);
    s->entries = NULL;
    s->count = 0;
    s->capacity = 0;
}

Registering and Unregistering Observers

Adding an observer resizes the array if needed:

bool subject_add_observer(Subject *s, void *context, ObserverCallback callback) {
    if (s->count == s->capacity) {
        size_t new_cap = s->capacity ? s->capacity * 2 : 4;
        ObserverEntry *tmp = realloc(s->entries, new_cap * sizeof(ObserverEntry));
        if (!tmp) return false;
        s->entries = tmp;
        s->capacity = new_cap;
    }
    s->entries[s->count].context = context;
    s->entries[s->count].callback = callback;
    s->count++;
    return true;
}

Unregistering is slightly more involved. We need to find the observer by its context pointer (or by a unique ID) and remove it, optionally preserving order:

bool subject_remove_observer(Subject *s, void *context) {
    for (size_t i = 0; i < s->count; i++) {
        if (s->entries[i].context == context) {
            // Shift remaining entries
            memmove(&s->entries[i], &s->entries[i+1],
                    (s->count - i - 1) * sizeof(ObserverEntry));
            s->count--;
            return true;
        }
    }
    return false;
}

Notifying All Observers

When an event occurs, we iterate through the observer list and call each callback:

void subject_notify(Subject *s, int event_type, void *event_data) {
    for (size_t i = 0; i < s->count; i++) {
        ObserverEntry *entry = &s->entries[i];
        entry->callback(entry->context, event_type, event_data);
    }
}

Putting It All Together: A Complete Example

Let’s build a simple simulation: a temperature sensor (the subject) that broadcasts temperature readings to multiple displays (observers).

Concrete Observer Implementations

// Display that logs temperature to console
void console_display_update(void *context, int event, void *data) {
    (void)context; // unused
    double *temp = (double*)data;
    if (event == 1) { // temperature changed
        printf("Console display: new temperature = %.2f°C\n", *temp);
    }
}

// Display that stores the last N readings
typedef struct {
    double readings[10];
    int index;
} LogDisplay;
void log_display_update(void *context, int event, void *data) {
    LogDisplay *log = (LogDisplay*)context;
    double *temp = (double*)data;
    if (event == 1) {
        log->readings[log->index % 10] = *temp;
        log->index++;
        printf("Log display: recorded reading #%d\n", log->index);
    }
}

Setting Up the Subject and Observers

int main(void) {
    Subject sensor;
    subject_init(&sensor, 4);

    // Create observers
    subject_add_observer(&sensor, NULL, console_display_update);

    LogDisplay log = {0};
    subject_add_observer(&sensor, &log, log_display_update);

    // Simulate temperature changes
    double temp = 23.5;
    subject_notify(&sensor, 1, &temp);

    temp = 24.1;
    subject_notify(&sensor, 1, &temp);

    subject_remove_observer(&sensor, NULL); // remove console display
    temp = 22.8;
    subject_notify(&sensor, 1, &temp);

    subject_destroy(&sensor);
    return 0;
}

This example demonstrates the core mechanics: observers can be added and removed at runtime, and each observer receives the event data independently.

Advanced Considerations for Robust Implementations

Real-world event systems demand more than the basic pattern. Here are several enhancements that production C code often requires.

Thread Safety

If the subject can be accessed from multiple threads, the observer list must be protected. A simple approach uses a mutex lock around list modifications and notifications. However, notifying while holding the lock can lead to deadlocks if an observer tries to modify the list in its callback. A common solution is to snapshot the list inside the lock, then notify without the lock:

void subject_notify_safe(Subject *s, int event, void *data) {
    ObserverEntry *snapshot;
    size_t count;
    pthread_mutex_lock(&s->lock);
    count = s->count;
    snapshot = malloc(count * sizeof(ObserverEntry));
    if (snapshot) {
        memcpy(snapshot, s->entries, count * sizeof(ObserverEntry));
    }
    pthread_mutex_unlock(&s->lock);

    if (snapshot) {
        for (size_t i = 0; i < count; i++) {
            snapshot[i].callback(snapshot[i].context, event, data);
        }
        free(snapshot);
    }
}

This pattern minimizes lock contention and avoids reentrancy issues.

Event Filtering and Typed Data

In many systems, observers only care about specific event types. You can extend the subject to maintain per-event-type observer lists, or you can pass the event type and let observers filter internally. The latter is simpler but less efficient for large numbers of observers and events. For high-performance systems (e.g., embedded firmware), a multicast table indexed by event ID is preferable.

Using a tagged union for event data (e.g., a struct with a type field and a union) gives you type safety at runtime:

typedef enum {
    EVENT_TEMPERATURE,
    EVENT_PRESSURE,
    EVENT_ALARM
} EventId;

typedef struct {
    EventId id;
    union {
        double temperature;
        int pressure;
        char *alarm_msg;
    } data;
} Event;

Each observer then casts the event_data pointer to Event* and inspects the id field.

Memory Ownership and Lifecycle

Who owns the context pointers added to the subject? The observer pattern usually implies that the observer is responsible for its own context. The subject should not attempt to free the context. If the observer’s lifecycle is shorter than the subject’s, it must unregister itself before destruction. For complex systems, consider using weak references or a garbage-collected pool.

Real-World Applications of the Observer Pattern in C

The Observer pattern appears in a wide range of C software, from operating system kernels to embedded firmware and game engines.

  • GUI toolkits (e.g., GTK, EFL) use signal/slot implementations that are essentially observer mechanisms. Widgets emit signals, and registered callbacks handle events like button clicks or window resizes.
  • Embedded sensor networks – a central controller monitors a temperature sensor subject and notifies logging, alerting, and display observers.
  • Event-driven state machines – state transitions trigger notifications to listeners (UI updates, loggers, watchdog timers).
  • Network servers – an I/O multiplexer (like epoll) acts as a subject, notifying handler observers when sockets become readable or writable.
  • Game engines – physics engines notify observers when collisions occur, allowing audio, particle, and gameplay systems to react.

For a deeper dive into the theoretical background, refer to the Wikipedia article on the Observer pattern. If you need a more formal introduction to design patterns in general, the classic Design Patterns: Elements of Reusable Object-Oriented Software (the GoF book) remains an excellent resource, though its examples are in C++ and Smalltalk.

Alternatives to the Observer Pattern in C

Not every event-driven situation demands a full observer pattern. Consider these alternatives:

  • Simple callback structs – if you only have one or two fixed observers, you can store function pointers directly in the subject. No dynamic list needed.
  • Publish-subscribe via message queues – particularly in multi-process or distributed systems, a central message broker (e.g., ZeroMQ, RabbitMQ) decouples producers and consumers more thoroughly than an in-process observer list.
  • Event loops with handler tables – many embedded systems use a fixed-size dispatch table indexed by event ID. This is faster and deterministic, but less flexible (no runtime addition of observers).
  • Signals and slots – libraries like libsigc++ (C++) or the csignal project for C provide type-safe observer implementations.

Choosing the right approach depends on your performance requirements, memory constraints, and the desired level of dynamism.

Common Pitfalls When Implementing the Observer Pattern in C

Even experienced C developers can stumble on a few subtle issues:

  1. Modifying the observer list during notification – if an observer’s callback removes or adds an observer, the iterator in subject_notify may become invalid. Always snapshot the list or defer modifications.
  2. Memory leaks from observer list – forgetting to call subject_destroy when the subject is no longer needed will leak the array of observer entries.
  3. Dangling context pointers – if an observer is destroyed before it unregisters, the subject may call a function through an invalid context. Use reference counting or lifecycle hooks to enforce proper unregistration.
  4. Thread abuse – mixing atomic operations and locks incorrectly can lead to data races or deadlocks. Consider using lock-free data structures for extremely high-frequency events.

A great resource for understanding these pitfalls in a broader context is the "Design Pattern Evolution" paper by Erich Gamma et al. (PDF), which discusses how design patterns have been adapted in modern programming.

Conclusion

The Observer pattern in C provides a clean, decoupled way to manage event-driven behavior. By using function pointers, dynamic arrays, and careful memory management, you can build notification systems that are both flexible and efficient. The implementation we’ve covered here—subject initialization, observer registration, notification, and unregistration—forms a solid foundation.

Advanced topics such as thread safety, event filtering, and lifecycle management push the pattern beyond toy examples into production-ready code. Whether you’re working on embedded firmware, a desktop application, or a networked service, the Observer pattern will serve you well as a reliable tool for building scalable, maintainable systems.

For further reading on advanced C techniques, see the C-FAQ and the cppreference C library documentation.