Concurrency-Aware Code Property Graph (CCPG)

• CCPG is defined as an extension of the standard CPG by integrating concurrency-specific nodes and edges, making thread interactions explicit.
• It enriches program graphs with representations for thread creation/join, lock/unlock, and critical sections to support precise bug localization.
• Integration with CodeBERT and RGCN significantly improves bug detection performance, yielding higher recall and F1 scores in experiments.

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 (Feng et al., 28 Aug 2025).

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 (Feng et al., 28 Aug 2025). 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 (Feng et al., 28 Aug 2025).

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$ (Feng et al., 28 Aug 2025).

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 (Feng et al., 28 Aug 2025).

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 (Feng et al., 28 Aug 2025).

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 (Feng et al., 28 Aug 2025).

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=\{V_{block} \cup V_{unblock}\}$0, $V=\{V_{block} \cup V_{unblock}\}$1
Added relations	Syntax, control, data dependencies	$V=\{V_{block} \cup V_{unblock}\}$2 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 (Feng et al., 28 Aug 2025). 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 $V=\{V_{block} \cup V_{unblock}\}$3. It defines $V=\{V_{block} \cup V_{unblock}\}$4, $V=\{V_{block} \cup V_{unblock}\}$5, and a function-node map $V=\{V_{block} \cup V_{unblock}\}$6. For each function graph $V=\{V_{block} \cup V_{unblock}\}$7, the algorithm adds its start and end nodes $V=\{V_{block} \cup V_{unblock}\}$8 to $V=\{V_{block} \cup V_{unblock}\}$9 and adds $E=\{E_{cpg} \cup E_{sync}\}$0 to the CCPG. It then iterates over each node $E=\{E_{cpg} \cup E_{sync}\}$1 in each graph $E=\{E_{cpg} \cup E_{sync}\}$2 and applies concurrency-specific augmentation rules (Feng et al., 28 Aug 2025).

For nodes classified as TCF.create, the algorithm adds edge $E=\{E_{cpg} \cup E_{sync}\}$3 to $E=\{E_{cpg} \cup E_{sync}\}$4. For nodes classified as TCF.join, it adds edge $E=\{E_{cpg} \cup E_{sync}\}$5 to $E=\{E_{cpg} \cup E_{sync}\}$6 and adds $E=\{E_{cpg} \cup E_{sync}\}$7 to $E=\{E_{cpg} \cup E_{sync}\}$8. For nodes classified as SP.lock, it tracks $E=\{E_{cpg} \cup E_{sync}\}$9 as a lock/unlock node to $V_{block}$0 and adds edge $V_{block}$1 to $V_{block}$2 (Feng et al., 28 Aug 2025).

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 (Feng et al., 28 Aug 2025). 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 (Feng et al., 28 Aug 2025).

For a node $V_{block}$3 corresponding to statement $V_{block}$4, the initial embedding is defined as

$V_{block}$5

so the node representation is obtained from CodeBERT over BPE-tokenized code (Feng et al., 28 Aug 2025). 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

$V_{block}$6

and the paper notes that the typesetting is imperfect, while the intended meaning is the standard RGCN formulation with relation types $V_{block}$7, neighbors $V_{block}$8, normalization constant $V_{block}$9, relation-specific weight matrix $V_{unblock}$0, self-loop weight $V_{unblock}$1, and nonlinearity $V_{unblock}$2 (Feng et al., 28 Aug 2025). 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

$V_{unblock}$3

and the bug probability as

$V_{unblock}$4

(Feng et al., 28 Aug 2025). 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 (Feng et al., 28 Aug 2025). 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 (Feng et al., 28 Aug 2025). 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 (Feng et al., 28 Aug 2025).

The localization objective is given as

$V_{unblock}$5

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

$V_{unblock}$6

where $V_{unblock}$7 is the number of edges with synchronization primitives, $V_{unblock}$8 is the number of blocking nodes, and $V_{unblock}$9 are hyperparameters (Feng et al., 28 Aug 2025). 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 (Feng et al., 28 Aug 2025). 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 1, 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 (Feng et al., 28 Aug 2025). 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 (Feng et al., 28 Aug 2025). 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 (Feng et al., 28 Aug 2025). 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 (Feng et al., 28 Aug 2025).