CONCUR: Benchmarking LLMs for Concurrent Code Generation

Dit paper introduceert CONCUR, een nieuw benchmark voor het evalueren van de vaardigheid van Large Language Models om concurrerende code te genereren, een domein dat complexer is dan sequentiële code en specifieke bugs zoals race conditions en deadlocks kent.

De kern

Stel je voor dat je een team van super-intelligente robot-assistenten (deze "Large Language Models" of LLM's) hebt die geweldig zijn in het schrijven van code, net als een programmeur. Ze kunnen makkelijk een simpele lijst met nummers maken of een calculator bouwen. Maar wat gebeurt er als je ze vraagt om een complex, drukke fabriek te bouwen waar honderden werknemers tegelijkertijd aan dezelfde machine werken?

Dat is precies wat dit onderzoek, genaamd CONCUR, onder de loep neemt.

Hier is het verhaal in simpele taal, met een paar creatieve vergelijkingen:

1. Het Probleem: De "Eenzame" Robot

Tot nu toe hebben we robots getest op sequentiële code. Dat is als een robot die een taak één voor één doet: eerst een boterham smeren, dan de toast maken, dan de koffie zetten. Alles gebeurt in een rechte lijn.

Maar echte software in de echte wereld werkt vaak als een drukke supermarkt op een zaterdag.

• Veel mensen (draden/threads) doen dingen tegelijk.
• Ze moeten wachten op elkaar (synchronisatie).
• Als ze niet goed afspreken, ontstaat er chaos:
  • Deadlock: Twee mensen staan vast in een smalle gang, beide wachten tot de ander opzij gaat, en niemand komt erdoor.
  • Race Condition: Twee mensen grijpen tegelijk naar de laatste melkdoos. De ene pakt hem, maar de ander denkt dat hij nog daar staat, en er ontstaat verwarring.

De bestaande tests voor robots keken alleen naar de "boterham-smeren"-taken. Ze wisten niet of de robot een fabriek kon bouwen zonder dat alles vastliep.

2. De Oplossing: De "CONCUR" Testbaan

De onderzoekers hebben een nieuwe testbaan bedacht, CONCUR.
Stel je voor dat ze een mini-fabriek hebben gebouwd met 115 verschillende scenarios (zoals "maak een wachtlijst" of "deel een pen tussen 5 mensen").

• De Basis: Ze namen 43 klassieke problemen uit een leerboek.
• De Variatie: Ze maakten 72 "mutanten" (verdraaide versies) van die problemen, zodat de robots niet zomaar het antwoord uit hun geheugen konden halen.
• De Regels: De robots moesten Java-code schrijven die precies deed wat er gevraagd werd, zonder externe hulpmiddelen.

3. De Scheidsrechter: De "Tijdmachine" (Model Checking)

Dit is het coolste deel. Hoe weet je of een robot een fabriek heeft gebouwd die altijd werkt, en niet alleen toevallig goed werkt op het moment dat je ernaar kijkt?

Normale tests draaien de code één keer. Als het goed gaat, is het goed. Maar in een drukke fabriek kan de volgorde van gebeurtenissen elke keer anders zijn.

De onderzoekers gebruikten een tool genaamd Java PathFinder (JPF).

• De Vergelijking: Stel je voor dat je een robot een labyrint laat lopen. Een normale test laat de robot één keer lopen. Als hij de uitgang vindt, is hij geslaagd.
• De JPF-methode: De JPF is als een tijdmachine die de robot elke mogelijke route door het labyrint laat lopen, tegelijkertijd. Hij probeert elke mogelijke combinatie van wie er eerst doet wat.
• Als de robot een foutje maakt (bijvoorbeeld: "Ah, als ik eerst wacht en jij eerst, dan botsen we"), vindt de tijdmachine dat direct. Hij zegt: "Niet goed! Je hebt een Deadlock gevonden!"

4. Wat Vonden Ze? (De Resultaten)

De onderzoekers testten 23 van de slimste robots ter wereld. Het nieuws is gemengd:

• Ze zijn slim, maar niet perfect: De beste robots (zoals GPT-5) haalden ongeveer 77% tot 91% van de tests goed (afhankelijk van hoe vaak je ze een kans gaf). Dat klinkt goed, maar voor een fabriek is 10% fouten veel te gevaarlijk.
• De "Eenzame" Robots: Veel robots schreven code die eruitzag alsof het een fabriek was, maar in werkelijkheid deden ze alles één voor één (alsof er maar één werknemer was). Ze gebruikten de juiste woorden, maar geen echte samenwerking. De testbaan ving dit op.
• De Valstrik van de "Schone Kleren": Ze keken ook naar een meetlat die "CodeBLEU" heet. Die meet hoe goed de code eruitziet (zoals de lettertjes en de structuur).
  • Vergelijking: Het is alsof je een auto beoordeelt op hoe mooi de lak is.
  • Het probleem: Een auto kan een prachtige lak hebben, maar als de motor niet werkt, is hij waardeloos. De onderzoekers ontdekten dat CodeBLEU geen goede voorspeller is voor of de code echt werkt. Je kunt code hebben die er perfect uitziet, maar die in de praktijk vastloopt.

5. De Conclusie

Dit onderzoek zegt: "We moeten stoppen met alleen kijken naar hoe mooi de code eruitziet."

Om te weten of robots echt complexe, drukke systemen kunnen bouwen, moeten we ze testen in een omgeving die alle mogelijke chaos simuleert. De huidige robots zijn goed in het schrijven van simpele code, maar ze hebben nog veel moeite met het begrijpen van de subtiele, chaotische interacties die nodig zijn in een echte, multithreaded wereld.

Kort samengevat:
De robots kunnen een mooi verhaal schrijven, maar als je ze vraagt om een orkest te dirigeren waar iedereen tegelijkertijd speelt, raken ze vaak de maat kwijt. De CONCUR-test is de nieuwe dirigent die luistert naar elke noot, elke keer opnieuw, om te zien of het echt een symfonie wordt of gewoon lawaai.

Technische samenvatting

Hier is een gedetailleerde technische samenvatting van het paper "CONCUR: BENCHMARKING LLMS FOR CONCURRENT CODE GENERATION" in het Nederlands.

Probleemstelling

Hoewel Large Language Models (LLMs) succesvol worden ingezet voor het genereren van sequentiële code, ontbreekt er een robuuste benchmark om hun capaciteit om concurrente code (meerdere threads die parallel draaien) te genereren, te evalueren. Bestaande benchmarks focussen voornamelijk op sequentiële code en missen de specifieke complexiteit van concurrentie, zoals:

• Niet-determinisme: Threads kunnen op willekeurige volgorde worden gepland.
• Unieke fouten: Concurrente code is vatbaar voor bugs die in sequentiële code niet voorkomen, zoals deadlocks, race conditions (data races) en starvation.
• Beperkingen van bestaande evaluatie: Statiche metrics (zoals CodeBLEU) meten alleen oppervlakkige syntactische overeenkomst en missen semantische correctheid. Dynamische evaluatie via unit-tests is ontoereikend omdat het niet alle mogelijke thread-interleavings (draadplanningen) kan testen, waardoor defecte programma's onterecht als correct worden gemarkeerd.

Methodologie: De CONCUR Benchmark

Om deze kloof te dichten, hebben de auteurs CONCUR ontwikkeld, de eerste benchmark specifiek gericht op concurrente codegeneratie. De methodologie bestaat uit drie pijlers:

1. Dataset Constructie

• Oorsprong: De dataset bevat 43 basisproblemen afgeleid van een standaard concurrentiehandboek.
• Mutaties: Om memorisatie door LLMs te voorkomen en de diversiteit te vergroten, zijn er 72 geverifieerde mutaties gegenereerd (via prompting van een ander model en handmatige validatie).
• Totaal: De benchmark bestaat uit 115 unieke probleeminstanties.
• Prompt Engineering: De prompts zijn gestructureerd om Java 8-code te genereren. Ze bevatten expliciete beperkingen (bijv. maximum aantal threads en iteraties) om de staatruimte (state space) beheersbaar te houden voor verificatie.
• Ground Truth: Voor elk probleem is een volledig uitvoerbaar referentieprogramma in Java 8 samengesteld en gevalideerd.

2. Evaluatie Framework (Verificatie)

In plaats van alleen te vertrouwen op compilatie of unit-tests, gebruikt CONCUR Model Checking via Java PathFinder (JPF).

• Stap 1: Compilatie: Code moet eerst compileren in een schone Java 8-omgeving zonder externe bibliotheken.
• Stap 2: Model Checking (JPF): JPF exploreert systematisch alle mogelijke thread-interleavings binnen een vooraf gedefinieerde diepte en tijdslimiet.
• Detectie van Fouten: Het framework detecteert specifieke foutcategorieën:
  • Deadlocks (DL): Threads die elkaar blokkeren.
  • Race Conditions (RC): Ongesynchroniseerde toegang tot gedeelde variabelen.
  • Starvation (SV): Threads die nooit worden gepland.
  • Single Thread (ST): Een kritieke categorie waarbij de code wel thread-veilige structuren gebruikt, maar feitelijk alleen in één thread draait (geen echte concurrentie).
  • Uncaught Exceptions (UE) en andere runtime fouten.

3. Beperkingen en Strategie

Om "state-space explosion" (het onbeheersbaar groeien van het aantal mogelijke staten) te voorkomen, worden threads en iteraties strikt gebonden. De zoekdiepte in JPF wordt ingesteld op 10 keer de diepte van de ground-truth oplossing, wat zorgt voor een grondige maar haalbare verificatie.

Belangrijkste Bijdragen

1. De CONCUR Benchmark: Een dataset van 115 concurrentieproblemen met gestructureerde prompts en Java 8 ground-truth implementaties.
2. Automatisch Validatie Framework: Een innovatieve aanpak die JPF gebruikt om de volledige staatruimte van gegenereerde code te exploreren, in plaats van te vertrouwen op statische metrics of beperkte testen.
3. Gedetailleerde Evaluatie: Een analyse van 23 state-of-the-art LLMs (zowel proprietary APIs als open-source modellen) die hun zwakke punten in concurrente code blootlegt.
4. Open Source: De dataset, tools en een publieke leaderboard zijn beschikbaar gesteld voor de gemeenschap.

Resultaten

De auteurs hebben 23 LLMs getest (o.a. GPT-5, Claude Opus, Gemini, Llama 3.3, Qwen). De belangrijkste bevindingen zijn:

• Prestaties: Zelfs de beste modellen (zoals GPT-5) bereiken een pass@1 score van ongeveer 77% en een pass@3 van 91%. Dit betekent dat zelfs geavanceerde modellen frequent falen bij het genereren van correcte concurrente code.
• Invloed van k (aantal generaties): De prestaties verbeteren aanzienlijk bij het genereren van meerdere opties per prompt (pass@3), wat suggereert dat veel modellen de oplossing "bijna" vinden maar niet consistent correct zijn.
• Foutanalyse:
  • Syntaxfouten en ontbrekende imports zijn de meest voorkomende compilatiefouten.
  • Race conditions en deadlocks zijn de meest frequente fouten die door JPF worden gedetecteerd.
  • Single Thread (ST) fouten: Een significant aantal modellen genereert code die syntactisch correct is en thread-veilige bibliotheken gebruikt (zoals ConcurrentHashMap), maar feitelijk geen enkele extra thread start. Dit wordt door JPF correct als een fout gedetecteerd.
  • Geen starvation: Geen enkel geval van starvation werd gevonden, waarschijnlijk vanwege de lage complexiteit en het gebonden aantal threads.
• CodeBLEU is onbetrouwbaar: Er is een zwakke correlatie gevonden tussen de CodeBLEU-score (een statische similariteitsmetric) en de werkelijke correctheid van de concurrente code. Modellen met hoge CodeBLEU-scores konden toch fundamentele concurrentiebugs bevatten. Dit onderstreept dat statische metrics ontoereikend zijn voor concurrente code.
• Validatie: Een handmatige audit van 115 door het systeem als "correct" gemarkeerde programma's bevestigde een precisie van 92%, wat aantoont dat het JPF-framework zeer betrouwbaar is, hoewel het soms functionele vereisten (zoals specifieke outputwaarden) kan missen als er geen expliciete assertions zijn.

Significantie

Dit paper is een mijlpaal in de evaluatie van LLMs voor software engineering. Het demonstreert dat:

1. Concurrente code genereren aanzienlijk moeilijker is dan sequentiële code genereren voor huidige LLMs.
2. Bestaande evaluatiemethoden (zoals CodeBLEU en simpele unit-tests) onvoldoende zijn om de kwaliteit van concurrente code te beoordelen.
3. Model checking (zoals JPF) essentieel is voor een robuuste evaluatie, omdat het niet-deterministische bugs kan opsporen die bij normaal testen onzichtbaar blijven.

De CONCUR benchmark biedt een nieuwe standaard voor onderzoekers en ontwikkelaars om de echte capaciteiten van AI-modellen op het gebied van complexe, veilige en correcte multithread-programmering te meten en te verbeteren.