Backend: static

The static backend is a simple, lightweight group management implementation for groups with fixed membership. Once initialized, the group membership cannot change.

When to use

Use the static backend when:

• Group membership is known at initialization and won’t change

• You’re using MPI and all processes start together

• You want minimal overhead and no centralized coordination

• You don’t need fault tolerance or dynamic membership

Characteristics

Fixed membership: Once the group is initialized, members cannot join or leave.

No coordination: There is no centralized coordinator. Each member has a local copy of the group view.

Low overhead: Minimal resource usage since there’s no dynamic management.

Deterministic: Group membership is always the same across all members.

Configuration

In Bedrock configuration:

{
    "providers": [
        {
            "type": "flock",
            "provider_id": 42,
            "config": {
                "bootstrap": "mpi",
                "group": {
                    "type": "static",
                    "config": {}
                },
                "file": "mygroup.flock"
            }
        }
    ]
}

The static backend takes an empty configuration object {} as it has no configurable options.

In C code

/*
 * (C) 2024 The University of Chicago
 *
 * See COPYRIGHT in top-level directory.
 */
#include <assert.h>
#include <stdio.h>
#include <margo.h>
#include <flock/flock-server.h>
#include <flock/flock-bootstrap.h>

int main(int argc, char** argv)
{
    // Initialize Margo
    margo_instance_id mid = margo_init("na+sm", MARGO_SERVER_MODE, 0, 0);
    assert(mid);

    // Initialize provider args
    struct flock_provider_args args = FLOCK_PROVIDER_ARGS_INIT;
    flock_group_view_t initial_view = FLOCK_GROUP_VIEW_INITIALIZER;
    args.initial_view = &initial_view;

    // Bootstrap using self
    uint16_t provider_id = 42;
    flock_group_view_init_from_self(mid, provider_id, &initial_view);

    // Configure with static backend
    // Static backend: group membership cannot change after initialization
    const char* config =
        "{"
        "  \"group\": {"
        "    \"type\": \"static\","
        "    \"config\": {}"
        "  }"
        "}";

    // Register provider with static backend
    flock_provider_t provider;
    int ret = flock_provider_register(mid, provider_id, config, &args, &provider);
    assert(ret == FLOCK_SUCCESS);

    printf("Flock provider registered with STATIC backend\n");
    printf("Group membership is fixed and cannot change\n");
    printf("Initial group size: %zu\n", initial_view.members.size);

    // Wait for finalize
    margo_wait_for_finalize(mid);

    return 0;
}

How it works

With the static backend:

1. The group view is initialized once at provider creation

2. The view is stored locally in each member

3. No updates or synchronization occur after initialization

4. Queries return the static view

This means:

• flock_group_get_view always returns the initial view

• There are no membership change notifications

• No network communication is needed for group queries

Best practices

Use with appropriate bootstrap methods:

• mpi: All MPI ranks form a static group

• file: Multiple processes load the same static view

• self: Single-member group (can be useful for testing)

Avoid with dynamic scenarios:

• Don’t use join bootstrap with static backend (joining won’t work)

• Don’t expect fault tolerance (failed members stay in the view)

• Don’t try to add/remove members programmatically

File persistence:

Always specify a file option to persist the group view. This is an easy way for client processes to lookup the view later.

Limitations

The static backend has several limitations:

1. No dynamic membership: Cannot add or remove members after initialization

2. No fault tolerance: Failed members remain in the view

3. No membership updates: View never changes

4. Join not supported: Processes can’t join after initialization

If you need any of these capabilities, use the Backend: centralized instead.

Performance

The static backend has excellent performance characteristics:

• Zero runtime overhead: No coordination or communication after initialization

• Minimal memory: Only stores the initial view

• Instant queries: No network calls needed

This makes it ideal for HPC applications where group membership is predetermined and fixed.