Cairo context corruption when shared across threads without external locking

Direct answer

Creating one cairo_t per thread on a shared image surface does not eliminate data races. Surface-level races persist because all contexts write into the same pixel buffer and share surface-level state (status, snapshots, fallback images). No Cairo backend documents a guarantee of thread-safe rasterization into the same surface from multiple contexts; accidental tolerance on image or platform backends is not a production contract.

The portable correctness strategy is to confine each cairo_t to a single thread and never allow two contexts to target the same surface concurrently. To avoid serializing unrelated drawing work, partition the scene into independent surfaces per thread (or per tile), then composite them sequentially under a single owner thread or a short lock around only the composition step.

Why per-thread contexts on one surface still race

• cairo_t owns mutable path, source, matrix, clip, and font state with no internal synchronization; the documented contract is single-thread per context.
• Only cairo_surface_t reference counting is thread-safe. Drawing operations, status changes, snapshots, and backend rasterization are not covered by that guarantee.
• When multiple contexts draw into the same image surface, their rasterization calls interleave writes to the shared pixel buffer. This can corrupt pixel data, surface status, snapshot contents, or fallback images, even if the drawing regions do not visually overlap.
• Vector backends (PDF, SVG, PostScript) serialize content streams; concurrent contexts on one such surface will interleave output and corrupt the document regardless of pixel overlap.

Synchronization strategies that preserve correctness

Option A: Independent surfaces + sequential composite (recommended)

1. Each worker thread creates its own image surface (cairo_image_surface_create) and draws exclusively on it with a thread-local cairo_t.
2. After all workers finish, a single thread (or a short critical section) composites the finished surfaces onto the final target surface using cairo_set_source_surface / cairo_paint.
3. No drawing work is serialized; only the final composite step requires mutual exclusion.

Option B: Shared surface guarded by a mutex

1. Protect the shared surface with a mutex that covers the entire lifetime of each cairo_t operation sequence (create, draw, destroy).
2. This serializes all drawing on that surface, which may be acceptable for low-contention workloads but defeats the goal of concurrent rendering.

Option C: Tile-based rendering with disjoint regions (advanced)

If the backend supports it (e.g., image surface with known stride), you can assign non-overlapping rectangular tiles to each thread, each with its own cairo_t clipped to its tile. However, Cairo does not expose a formal "disjoint tile" contract, and surface-level state (status, snapshots) is still shared, so this remains unsupported and fragile. Prefer Option A.

Backend-specific guarantees

None. The Cairo manual makes no thread-safety promise for rasterization into a shared surface from multiple contexts. Image, Xlib, Quartz, Win32, PDF, SVG, and PostScript backends all exhibit undefined behavior under concurrent use. Observed "clean" output on one platform or version is not evidence of safety; races may be latent, appear only under load, or surface with sanitizers.

Verification steps for your build

1. Confirm the Cairo version and read the thread-safety and reference-counting notes in the installed cairo.h or the Cairo manual for that release.
2. Build a stress test that shares one image surface across N threads each with its own cairo_t and run it under ThreadSanitizer (-fsanitize=thread) and Helgrind to observe whether surface-level races are reported.
3. Repeat the stress test across the backends you ship (image, xlib, quartz, win32, PDF, SVG) and compare output hashes against a single-threaded reference.
4. In code review or static analysis, assert that no cairo_t is reachable from two threads simultaneously and that every shared surface is guarded by one mutex or owned by a single thread.

One missing diagnostic detail

Which Cairo version and which backends (image, xlib, quartz, win32, PDF, SVG, etc.) are you targeting in production? The exact version matters because internal rasterization paths, fallback images, and snapshot behavior can change between releases.