---
title: Concurrency-Aware Code Property Graph (CCPG)
url: https://www.emergentmind.com/topics/concurrency-aware-code-property-graph-ccpg
type: topic
---

# Concurrency-Aware Code Property Graph (CCPG)

Searching arXiv for the specified paper to ground the article in the current record.
Concurrency-Aware Code Property Graph (CCPG) is a program-graph representation introduced to extend the standard Code Property Graph (CPG) with explicit concurrency semantics for deep-learning-based concurrency bug detection and localization. In the underlying formulation, a standard CPG merges AST, CFG, and PDG into a unified program graph, but does not model concurrency relations well, especially thread creation/join behavior, synchronization primitives, critical sections, and blocking behavior caused by locks. CCPG augments that representation with concurrency-specific nodes and edges so that a graph neural network can learn features relevant to concurrency bugs such as data races, synchronization errors, and other thread-interaction issues [2508.20911].

## 1. Research context and motivation

The introduction of CCPG is tied to three limitations identified for existing deep-learning methods for concurrency bug analysis: the absence of large and dedicated datasets of diverse concurrency bugs, insufficient representation of concurrency semantics, and the inability of binary classification alone to provide finer-grained debug information such as precise bug lines [2508.20911]. Within that framing, CCPG addresses the representational deficit rather than the dataset or interpretability components in isolation.

The motivating argument is that prior representations are either too sequential if token-based or, if graph-based, omit explicit concurrency structure. The paper states that such models therefore cannot adequately model complex interactions among threads and shared resources. In particular, graph-based models are described as struggling with thread interactions, hierarchical locking mechanisms, and other concurrency-specific dependencies. CCPG is introduced to inject these missing semantics directly into the graph representation [2508.20911].

This design position places CCPG at the intersection of program analysis and representation learning. The key claim is not merely that concurrency information matters, but that it should be made explicit in the graph topology rather than left implicit in syntax, control flow, or data dependency structure. This suggests that the representation itself is treated as a primary bottleneck for learning-based concurrency analysis.

## 2. Structural definition and represented semantics

CCPG is explicitly defined as an extension of the traditional CPG by incorporating concurrency edges, blocking nodes, and synchronization-related relations. The paper gives the formal definition

$$
G=(V,E)
$$

with

$$
V=\{V_{block} \cup V_{unblock}\}
$$

and

$$
E=\{E_{cpg} \cup E_{sync}\}
$$

where \(V_{block}\) denotes vertices in critical regions, \(V_{unblock}\) denotes vertices corresponding to operations that release synchronization primitives, \(E_{cpg}\) denotes all edges from the base CPG, \(E_{sync}\) denotes edges associated with synchronization primitives, and \(V \cap E = \emptyset\) [2508.20911].

The extension is operationalized through new graph elements associated with concurrency structure. The paper states that the original CPG is enhanced by “constructing blocking nodes and edges associated with synchronization primitives.” More concretely, CCPG augments the CPG with nodes in critical regions, nodes that release synchronization primitives, and edges representing synchronization behavior [2508.20911].

The concurrency semantics captured by CCPG are centered on thread creation and joining, lock-based critical sections, synchronization relations, and execution ordering or concurrency structure. The paper defines synchronization primitives as

$$
SP=\{lock, unlock\}
$$

and thread control functions as

$$
TCF=\{create, join\}
$$

and then analyzes calls such as `pthread_create` and `pthread_join`. For `pthread_create`, the graph adds a synchronization or concurrency edge from the caller to the start node of the thread function. For `pthread_join`, an edge is connected directly to `pthread_join` because Joern lacks enough function-specific information and pointer analysis to resolve the exact target [2508.20911].

Within each method’s CFG, the method searches for paths between `pthread_mutex_lock` and `pthread_mutex_unlock`. Nodes along those paths are marked as blocking nodes, corresponding to critical sections. The graph also includes edges associated with synchronization primitives, including lock/unlock relationships, create/join relations, and critical-section boundaries. The authors claim that these additional edges help capture inter-thread execution order, dependencies among threads, and synchronization-induced ordering [2508.20911].

| Component | In standard CPG | In CCPG |
|---|---|---|
| Core structure | AST + CFG + PDG | Base CPG plus concurrency-specific nodes and edges |
| Added vertices | Not specified for concurrency | \(V_{block}\), \(V_{unblock}\) |
| Added relations | Syntax, control, data dependencies | \(E_{sync}\) for synchronization behavior |

The paper does not describe detailed semantics for waits/signals, condition variables, barriers, or semaphores beyond general “keywords” in dataset filtering. Accordingly, the concrete CCPG construction is mainly about thread creation/join, mutex lock/unlock, critical sections, blocking nodes, and synchronization edges [2508.20911]. A common misconception would be to read CCPG as a fully general concurrency formalism; the paper supports a narrower interpretation centered on these specific POSIX-thread and mutex relations.

## 3. Construction algorithm and graph augmentation

The paper provides a simplified algorithm for CCPG creation whose input is a CPG, written as \(CPG=(G,E)\). It defines \(SP = \{lock, unlock\}\), \(TCF = \{create, join\}\), and a function-node map \(FN=f:(start,last)\). For each function graph \(g \in CPG\), the algorithm adds its start and end nodes \((g_s,g_l)\) to \(FN\) and adds \(g\) to the CCPG. It then iterates over each node \(v\) in each graph \(g\) and applies concurrency-specific augmentation rules [2508.20911].

For nodes classified as `TCF.create`, the algorithm adds edge \((v \to FN[g].s)\) to \(E_{sync}\). For nodes classified as `TCF.join`, it adds edge \((FN[g].l \to v)\) to \(E_{sync}\) and adds \(v\) to \(V_{block}\). For nodes classified as `SP.lock`, it tracks \(v\) as a lock/unlock node to \(V_{block}\) and adds edge \((v_1 \in V_{lock} \to v_2 \in V_{unlock})\) to \(E_{sync}\) [2508.20911].

The text clarifies several implementation details beyond the simplified pseudocode. The method traverses all methods in the CPG to identify entry and exit nodes, analyzes the call graph for thread-related POSIX calls, and walks CFG paths between lock and unlock to identify critical sections [2508.20911]. These clarifications are significant because the graph augmentation is not purely local: it combines call-graph information, CFG traversal, and synchronization-specific pattern extraction.

The resulting representation is therefore not just the original CPG with extra labels. It is a graph with new concurrency-aware vertices and edge types. This suggests that the authors view concurrency semantics as first-class relational structure rather than as node attributes alone.

## 4. Integration with CodeBERT and heterogeneous GNNs

CCPG serves as the input graph to the model’s graph learner. The pipeline given in the paper is: construct CCPG, embed each node with CodeBERT, apply RGCN, pool the graph representation, and predict bug or non-bug [2508.20911].

For a node \(n_i\) corresponding to statement \(s_i\), the initial embedding is defined as

$$
\mathcal{V}_i = CodeBERT(BPE(s_{i}))
$$

so the node representation is obtained from CodeBERT over BPE-tokenized code [2508.20911]. This ties CCPG’s structural augmentation to a pretrained code representation model rather than using handcrafted node features alone.

The heterogeneous graph convolution update is given as

$$
{h}_i^{(l+1)} = \sigma \left( {W}_0^{(l)} {h}_i^{(l)} + \sum_{r \in \mathcal{R} \sum_{j \in \mathcal{N}_i^r} \frac{1}{z_{i,r} {W}_r^{(l)} {h}_j^{(l)} \right)
$$

and the paper notes that the typesetting is imperfect, while the intended meaning is the standard RGCN formulation with relation types \(\mathcal{R}\), neighbors \(\mathcal{N}_i^r\), normalization constant \(z_{i,r}\), relation-specific weight matrix \(W_r^{(l)}\), self-loop weight \(W_0^{(l)}\), and nonlinearity \(\sigma\) [2508.20911]. The importance of CCPG’s multiple edge types appears here directly: RGCN can exploit them through relation-specific parameters.

The graph readout is defined as

$$
\mathcal{R}_k(\mathbf{G_k})=\sigma\left(\frac{1}{N}\sum_{i=1}^N h^{l+1}_i\right)
$$

and the bug probability as

$$
P(\mathbf{G_k})=\mathrm{Softmax}(\mathrm{MLP}(\mathcal{R}_k))
$$

[2508.20911]. The paper states that RGCN is appropriate because CCPG is a heterogeneous graph with multiple relation types, and reports that RGCN outperforms GCN and GAT in this setting. A plausible implication is that CCPG’s value is partly contingent on a learner capable of preserving relation-specific message passing rather than collapsing all edges into a homogeneous graph.

## 5. Role in bug detection and localization

In detection, CCPG is presented as the representation that makes concurrency structure explicit. The authors claim it helps the model capture complex interdependencies, execution order between threads, synchronization and critical-section structure, and race-prone shared-resource access patterns [2508.20911]. These are precisely the categories of behavior that are difficult to encode with purely sequential or non-concurrency-aware graph representations.

The paper provides ablation evidence on the DeepRace POSIX dataset. Reported results are:

- **Convul w/o CCPG**: Accuracy 61.83, Precision 70.03, Recall 77.34, F1 73.50  
- **Convul w/ CCPG**: Accuracy 75.68, Precision 78.32, Recall 94.60, F1 85.69

The paper states that CCPG yields at least 8.29% improvement in the measured metrics, with especially strong gains in recall and F1 [2508.20911]. Within the paper’s argument, this is the principal empirical support for the claim that concurrency-aware graph structure materially improves concurrency bug detection.

CCPG also underpins bug localization. The localization module applies SubgraphX on the CCPG-based GNN to identify important connected subgraphs that likely contain concurrency bugs. The authors emphasize that concurrency bugs often arise from multiple related nodes rather than isolated lines, and CCPG is useful because it preserves structural relations among those nodes [2508.20911].

The localization objective is given as

$$
\mathcal{G}^{*}_{s}=\underset{\left|\mathcal{G}_{s}\right| \leq N_{\min},{G}_{s}\in G}{\operatorname{argmax} \operatorname{S}\left(\mathcal{M}(\cdot), \mathcal{G}, \mathcal{G}_{s}\right)
$$

and the search is biased toward concurrency-related graph regions through

$$
\theta =\alpha N_{ce} +\beta N_{bn}
$$

where \(N_{ce}\) is the number of edges with synchronization primitives, \(N_{bn}\) is the number of blocking nodes, and \(\alpha,\beta\) are hyperparameters [2508.20911]. This means SubgraphX is guided toward subgraphs rich in concurrency semantics.

For localization, the reported Convul results are **Big-Vul: Acc 88.30, IoU 14.50** and **SARD: Acc 79.68, IoU 12.57**. Compared with the best baseline, the paper states about 4.5% improvement in IoU, and on Big-Vul at least 11% improvement in accuracy and 2.18% improvement in IoU [2508.20911]. The interpretation offered by the paper is that CCPG’s concurrency structure benefits both classification and precise line-level localization.

## 6. Example, claimed advantages, and scope of applicability

The paper includes Figure 2, titled *An Example of CCPG*, to illustrate the representation. The text states that the left side contains code in which `main` creates a thread, the thread manipulates a global variable `bignum`, and the access occurs inside a critical section. The figure is used to show how a conventional CPG is augmented with concurrency-related edges and nodes around thread creation, the thread function, shared-variable access, and critical-section boundaries [2508.20911]. Although the figure itself is not reproduced in the textual description, its function is clear: to make explicit the transformation from ordinary program structure to concurrency-aware structure.

The paper claims several advantages for CCPG over standard CPG and other program representations. These include explicit encoding of concurrency semantics, representation of thread interactions particularly create/join relations, modeling of critical sections via blocking nodes and sync edges, improved expressiveness for multi-threaded code, reduced missed concurrency context, and assistance for localization because the concurrency-sensitive structure is preserved as connected subgraphs [2508.20911]. These claims collectively define CCPG as the paper’s core graph representation innovation.

At the same time, the scope described in the paper is specific. The concrete construction focuses on thread create/join, mutex lock/unlock, critical sections, blocking nodes, and synchronization edges. The paper does not explicitly specify detailed semantics for waits/signals, condition variables, barriers, or semaphores beyond general keyword-based dataset filtering [2508.20911]. This bounds the generality of the representation as described. A plausible implication is that extensions would be required for richer synchronization APIs or non-POSIX concurrency models.

Taken together, CCPG is best understood as a concurrency-specialized extension of CPG designed for heterogeneous graph learning. Its contribution lies in making thread and synchronization structure explicit enough for CodeBERT-initialized RGCN models and SubgraphX-based explanation methods to detect and localize concurrency bugs more effectively in the experimental setting reported by the paper [2508.20911].

Source: https://www.emergentmind.com/topics/concurrency-aware-code-property-graph-ccpg