[Pthreads] Mutex misbruikt als soort semaphore.

[j.roeloffzen]

Beste Forum,

Ik heb een stuk C code in beheer (niet door mij geschreven) dat gebruikt een pthread_mutex_lock en pthread_mutex_unlock call. De unlock wordt in een andere thread dan de lock gedaan. Dit werkt toevallig maar is gedocumenteerd (in de manpage van pthread_mutex_lock) als "undefined behaviour". De mutex is default/non-robust geinitialiseert. Ik beschouw het als een bug maar dit veranderen kost enige tijd (Testen , qualificatie, etc ..)

Mijn vraag is hoe dit te benaderen, 2 keuzes:
A - "It ain't broken , don't fix it" Undefined behaviour blijft ongewijzigd, ook na evt OS updates.
B - De code kan beslist omvallen na een OS of library update, dus beslist fixen. Bijvoorbeeld de call returns nu een error.

Graag enig advies.

Jan Roeloffzen

[ Voor 0% gewijzigd door j.roeloffzen op 23-03-2026 14:56 . Reden: unintended smiley ]

[jeroen3]

Testcases toevoegen aan de unit tests die controleren of het "undefined" gedrag nog is wat je verwacht.

[GarBaGe]

Documenteren als "tech debt issue" en een ranking geven.
Dan kan je eraan beginnen wanneer het belangrijk genoeg is (in verhouding tot je overige werk / issues)

[j.roeloffzen]

jeroen3 schreef op maandag 23 maart 2026 @ 14:57:
Testcases toevoegen aan de unit tests die controleren of het "undefined" gedrag nog is wat je verwacht.

Vriendelijk bedankt voor het antwoord,.Het is geen slecht idee, maar als ik er vanuit moet gaan dat het kan omvallen (en dat was de eigenlijke vraag) kan ik het net zo goed vooraf fixen (optie B dus) . Het kan een behoorlijke tijd duren voor het ooit gereproduceerd wordt namelijk.

[j.roeloffzen]

GarBaGe schreef op maandag 23 maart 2026 @ 14:58:
Documenteren als "tech debt issue" en een ranking geven.
Dan kan je eraan beginnen wanneer het belangrijk genoeg is (in verhouding tot je overige werk / issues)

Bedankt voor je antwoord. Het is idd een bestaand JIRA issue en ong. in het midden vd backlog, wat betreft de ranking ...

[Xyrr]

Ik zou dit niet proberen af te vangen met een unit test, want dat biedt hier geen garantie. Of de undefined behavior tot problemen leidt kan zomaar verschillen per compiler of libc versie. Dus als je je unit test executable met een andere compiler(versie) maakt dan je productie executable (niet slim, maar zo'n fout is makkelijk gemaakt) of als het systeem waarop de executable wordt gebruikt een andere libc versie heeft dan het systeem waar je unit tests op draaien, dan kan een undefined behavior probleem er zo langs glippen.

Dus inderdaad gewoon aanmerken als tech debt, en naar prioriteit oplossen.

[farlane]

Dit werkt toevallig maar is gedocumenteerd (in de manpage van pthread_mutex_lock) als "undefined behaviour".

Hoe heb je bepaald dat het werkt eigenlijk?