If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/cameron314/concurrentqueue shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Mixed signals — read the receipts

• Last commit 2w ago
• 25+ active contributors
• Other licensed
• ⚠ Concentrated ownership — top contributor handles 53% of recent commits
• ⚠ Non-standard license (Other) — review terms
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live cameron314/concurrentqueue repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/cameron314/concurrentqueue.

What it runs against: a local clone of cameron314/concurrentqueue — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in cameron314/concurrentqueue | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 41 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of cameron314/concurrentqueue. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/cameron314/concurrentqueue.git
#   cd concurrentqueue
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of cameron314/concurrentqueue and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "cameron314/concurrentqueue(\\.git)?\\b" \\
  && ok "origin remote is cameron314/concurrentqueue" \\
  || miss "origin remote is not cameron314/concurrentqueue (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 41 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~11d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/cameron314/concurrentqueue"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

moodycamel::ConcurrentQueue is a high-performance, lock-free multi-producer multi-consumer queue for C++11 that uses atomic operations and CAS (Compare-And-Swap) primitives to eliminate mutex bottlenecks. It solves the problem of safely sharing work between threads without locks, achieving near-linear scaling and supporting bulk enqueue/dequeue operations that outperform even non-concurrent queues under contention. Single-header core design: the actual queue implementation lives in a header file (inferred to be in root or concurrentqueue/ directory based on naming), with benchmarks/benchmarks.cpp providing competitive performance tests against Boost and other queues. The benchmarks/boost/ subdirectory contains an embedded Boost.Atomic snapshot for cross-platform atomic operations without external Boost dependency.

C++ systems programmers and library authors building real-time systems, game engines, or high-throughput servers who need lock-free inter-thread communication without the limitations of Boost.Lockfree (which requires trivial destructors) or Intel TBB (which isn't fully lock-free and requires trivial constructors).

Highly mature and production-ready: this is a widely-adopted industrial-strength library (evidenced by 11MB of C++ code and extensive benchmarking infrastructure in benchmarks/benchmarks.cpp). The codebase shows careful platform-specific optimization for x86, ARM, PowerPC, and SPARC architectures via the embedded Boost.Atomic compatibility layer, though the lack of visible recent CI/CD setup and GitHub metadata in the provided file list suggests you should verify commit recency and test coverage separately.

Low risk: it's a single-header library with no external dependencies (contains its own Boost.Atomic copy), eliminating supply-chain concerns. The main risk is single-maintainer dependency (cameron314) — check GitHub for issue response time and contributor count. The non-linearizable design (per README) is a feature, not a bug, but could surprise teams expecting strict FIFO ordering across thread-coordinated producers.

No specific commit or PR data is visible in the provided file list. Check the GitHub repository's recent commits and issues to determine if this is in maintenance mode or actively developed. The presence of CMakeLists.txt and modern C++ suggests ongoing compatibility work, but you must verify the last commit date.

git clone https://github.com/cameron314/concurrentqueue.git
cd concurrentqueue
cmake . && make  # or just include the header in your C++ project

Since it's header-only, no build is strictly required; drop the include/ files into your project.

Daily commands: No traditional 'run' step; this is a header-only library. To run benchmarks: cd benchmarks && g++ -O3 -std=c++11 benchmarks.cpp -o bench && ./bench. Include concurrentqueue in your own C++ project via #include "concurrentqueue.h".

• concurrentqueue.h: Core single-header implementation of the lock-free queue algorithm and public API
• benchmarks/benchmarks.cpp: Competitive performance tests against Boost and TBB; use to validate changes don't regress throughput
• benchmarks/boost/atomic/detail/: Platform-specific atomic operation implementations (x86, ARM, PowerPC) that power the lock-free primitives
• CMakeLists.txt: Build configuration; modify to add platform-specific compiler flags or testing targets
• README.md: Feature claims and design rationale; read before modifying behavior to understand non-linearizable guarantees

For new queue features: modify the header file (path inferred as ./concurrentqueue.h or src/concurrentqueue.h). For platform support: edit benchmarks/boost/atomic/detail/ops_*.hpp files matching your target architecture. For benchmarking changes: update benchmarks/benchmarks.cpp. For documentation: edit README.md and add usage examples.

1. Non-linearizable semantics: elements come out in producer order, but NOT in global wall-clock order if producers co-ordinate externally. Don't assume FIFO across independent producer threads unless each thread strictly alternates produce-consume. 2. Exception safety assumptions: the queue doesn't throw, but element constructors/destructors/move-ops must be exception-safe or behavior is undefined. 3. Platform detection: the Boost.Atomic snapshot uses compile-time detection; ensure your target architecture is in benchmarks/boost/atomic/detail/ops_*.hpp or you'll fall back to emulated atomics (much slower). 4. No manual memory management cleanup: allocate-once is supported; if you deallocate and reuse the queue, test thoroughly—the lock-free logic can hide memory-order bugs.

• Lock-Free Programming — The entire queue avoids mutex locks via atomic operations; understanding lock-free guarantees (wait-free vs lock-free vs obstruction-free) is essential to reasoning about the queue's performance and correctness under contention.
• Compare-And-Swap (CAS) — CAS is the primitive building block that enables the queue to atomically update pointers without locks; you'll see it throughout benchmarks/boost/atomic/detail/ and must understand retry semantics.
• Memory Ordering & Barriers — The queue uses acquire/release memory barriers (via Boost.Atomic) to ensure visibility across threads; misunderstanding memory_order can silently break correctness on ARM or PowerPC.
• Hazard Pointers vs. Block Reclamation — This queue uses block-based memory reclamation (pre-allocate chunks) rather than hazard pointers; affects how you reason about deletion safety and memory footprint.
• Spurious Wakeups — BlockingConcurrentQueue adds condition variables; you must understand why waiting threads may wake without data and how the queue handles this in the blocking variant.
• Platform-Specific Atomics (x86 vs. ARM) — The benchmarks/boost/atomic/detail/ops_*.hpp files show that x86, ARM, and PowerPC have different atomic instruction costs and guarantees; performance tuning depends on your target platform.
• Move Semantics & RValue References — The README emphasizes C++11 move semantics to avoid copies; the queue leverages this for zero-copy enqueue/dequeue when possible, critical to achieving the advertised performance.

• cameron314/readerwriterqueue — Same author's SPSC (single-producer single-consumer) variant mentioned in README; lighter-weight if you don't need multi-producer.
• boost-cmake/boost — Contains Boost.Lockfree and Boost.Atomic (the external alternatives this repo's bundled Boost improves upon); useful for comparison benchmarking.
• oneapi-src/oneTBB — Intel's task-based parallelism library with concurrent_queue; mentioned in README as a performance and feature comparison point.
• abseil/abseil-cpp — Google's C++ library includes Abseil's synchronization primitives; ecosystem alternative for lock-free algorithms and testing patterns.
• facebook/folly — Meta's C++ library with its own lock-free MPMCQueue; different design tradeoff (uses hazard pointers instead of CAS); useful for benchmarking architecture differences.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for BlockingConcurrentQueue

The README mentions a low-overhead BlockingConcurrentQueue variant, but there's no visible test file in the repo structure. Given this is a lock-free queue library where correctness is critical, comprehensive unit tests covering blocking semantics (timeout behavior, spurious wakeups, exception safety) would be high-value. This would catch regressions and document expected behavior.

• [ ] Create tests/blockingqueue_tests.cpp with test cases for wait(), try_dequeue_for(), and try_dequeue_until()
• [ ] Test timeout edge cases and spurious wakeup handling
• [ ] Add tests for exception safety during blocking operations
• [ ] Integrate tests into CMakeLists.txt and benchmarks/benchmarks.cpp runner
• [ ] Test interaction between multiple waiting threads on empty queue

Add GitHub Actions CI for multi-platform compiler testing

The repo claims to be 'fully portable' with 'no assembly', but there's no visible CI configuration. Testing across GCC, Clang, and MSVC on Linux, macOS, and Windows (especially given the benchmarks/boost platform detection files) would catch ABI issues and compiler-specific bugs early. The extensive platform-specific boost files in benchmarks suggest this matters.

• [ ] Create .github/workflows/ci.yml with matrix for GCC/Clang/MSVC on Ubuntu/macOS/Windows
• [ ] Add C++11 and C++17 compilation variants to catch compatibility regressions
• [ ] Run benchmarks/benchmarks.cpp as a smoke test in CI
• [ ] Add compiler warning flags (-Wall -Wextra -Wpedantic) to catch quality issues
• [ ] Document CI results in README.md

Extract and document the queue's memory allocation strategy with examples

The README states 'Memory can be allocated once up-front, or dynamically as needed' and 'No artificial limitations on element types' but there's no specific documentation or examples showing how to use different allocation patterns. Users need concrete examples for pre-allocated vs. dynamic growth scenarios.

• [ ] Create docs/ALLOCATION_GUIDE.md explaining pre-allocation and dynamic growth with code examples
• [ ] Add example code in docs/examples/preallocation_example.cpp showing explicit capacity reservation
• [ ] Add example code in docs/examples/dynamic_growth_example.cpp showing unbounded allocation
• [ ] Document memory overhead per element and queue overhead in docs/PERFORMANCE.md
• [ ] Link allocation guide from README.md in features section

• Add unit tests for the BlockingConcurrentQueue variant (mentioned in README but no visible test suite in benchmarks/). Create tests/blocking_queue_test.cpp with timeout, spurious wakeup, and exception scenarios.
• Document the bulk enqueue/dequeue APIs with concrete examples in README.md. Search for try_dequeue_bulk in the header and add a 'Bulk Operations' section showing throughput benefits with code.
• Add Meson build support (meson.build file) alongside CMakeLists.txt for projects using Meson. Reference how other header-only libraries structure this.

This is a C++ header-only concurrent queue library with a relatively strong security posture for its domain. The primary concern is the presence of vendored, potentially outdated Boost libraries in the benchmarks directory that may not receive timely security updates. The codebase itself, being a low-level lock-free data structure without network/I/O operations, has minimal exposure to common web vulnerabilities (SQLi, XSS, etc.). However, the project lacks explicit security documentation, vulnerability disclosure policies, and dependency management best practices. Recommendations focus on modernizing dependency management and adding security governance documentation rather than addressing critical flaws in the queue implementation itself.

• Medium · Bundled Third-Party Dependencies Without Version Control — benchmarks/boost/. The codebase includes vendored Boost library headers in the benchmarks/boost directory. These are embedded third-party dependencies that may not be updated regularly, potentially carrying unpatched security vulnerabilities. The Boost Atomic library in particular has had security-relevant issues in the past. Fix: Use a package manager (Conan, vcpkg, or system package manager) to manage Boost dependencies instead of vendoring. Implement automated dependency scanning and update policies. If vendoring is necessary, maintain a clear record of versions and apply security patches promptly.
• Low · Lack of Security Documentation — Repository root. No explicit security policy, vulnerability disclosure process, or security guidelines are evident from the file structure. The README snippet does not mention any security considerations or best practices for users. Fix: Create a SECURITY.md file documenting: (1) how to responsibly report security issues, (2) security guarantees of the lock-free queue implementation, (3) known limitations or assumptions, (4) thread-safety guarantees and edge cases.
• Low · No SBOM or Dependency Tracking — Repository root, CMakeLists.txt. There is no Software Bill of Materials (SBOM), package lock file, or documented dependency versions. The CMakeLists.txt configuration is not provided, making it difficult to assess the full dependency chain and versions. Fix: Create and maintain an SBOM using tools like SPDX or CycloneDX. Document all direct and transitive dependencies with pinned versions. Use CMake to explicitly declare and version external dependencies.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.