Nieuwe tool moet code voor multithread applicaties veiliger maken

Met de komst van multicoreprocessors wordt multithreaded programmeren steeds belangrijker. Het bedrijf Coverity heeft een softwarepakket op de markt gebracht dat de ontwikkelaar hierbij moet assisteren.

Om optimaal gebruik te maken van de mogelijkheden van moderne multicoreprocessors moet een softwareontwikkelaar gebruik maken van meerdere threads in zijn programma. Door meerdere threads te gebruiken kunnen de cores simultaan instructies verwerken wat de verwerkingssnelheid uiteraard ten goede komt.

Het programmeren met meerdere threads is echter wel complexer en niet voor iedere programmeur weggelegd. Zo kan een zogenaamde race condition ontstaan; een situatie waarbij de uitkomst van een routine onverwacht is en afhangt van de tijd die de verschillende processen binnen de applicatie voor hun rekening nemen. Een ander probleem dat voor kan komen is de zogenaamde deadlock: twee verschillende processen wachten eeuwig op elkaar tot de ander klaar is.

Coverity Thread Analyzer for Java moet hier de helpende hand bieden. Het pakket kan tijdens het draaien van een programma bovenstaande problemen signaleren zodat de ontwikkelaar van het programma de nodige actie kan ondernemen. Het voordeel van de tool is ook dat het situaties kan herkennen die tijdens het testen niet naar voren komen, maar in zeldzame omstandigheden bij de klant wel voor problemen kunnen zorgen.

Naast het detecteren van bovenstaande problemen kan het programma ook helpen bij het omzetten van single threaded naar multi threaded code. Het programma signaleert data die door verschillende threads gedeeld wordt en adviseert waar locking toegepast moet worden. De tool draait op Windows, Linux, OS X en Solaris, en ondersteunt de Sun JDK en IBM's JVM vanaf versie 1.5 en BEA Jrockit vanaf versie 5.

Reacties (48)

[Verwijderd]

Echt revolutionair is dit niet. Wij hadden jarenlang NuMega Boundschecker en die deed ook al dingen als deadlock detection en dat soort ongein. En ik denk dat zij niet de enigen waren. Om dit nu te brengen als een nieuwe en bijzondere tool vind ik wat ver gaan.
Volgens mij heeft Intel ook een suite die dit soort dingen doet (vTune).

Kortom, weinig nieuws dus.

Bovendien ligt de toekomst in 'Implicit parallelism', oftewel, programmeertalen waarin je niet expliciet hoeft te threaden, maar waarbij er uit de context herleid wordt wat er parallel uitgevoerd kan worden (zie o.a. F#, een functionele programmeertaal). Functionele programmeertalen bouwen o.a. op het principe van 'referential transparency' (http://en.wikipedia.org/w...cy_%28computer_science%29). Dit soort talen vergt een compleet andere manier van denken, maar als we straks met processoren zitten die tientallen cores of meer hebben dan is expliciet threaden gewoon geen optie meer.

[RayNbow]

Bovendien ligt de toekomst in 'Implicit parallelism', oftewel, programmeertalen waarin je niet expliciet hoeft te threaden, maar waarbij er uit de context herleid wordt wat er parallel uitgevoerd kan worden

Het is nog niet echt zeker of je gratis veel parallelisme krijgt als je functioneel programmeert. Zie bijvoorbeeld Slides from BayFP concurrent and multicore Haskell talk (slide 26 o.a., video van de presentatie komt later online op de site).

(zie o.a. F#, een functionele programmeertaal)

F# heeft echter het probleem dat je heel gemakkelijk andere .NET methoden kunt aanroepen. Is je programma dan nog wel referentieel transparant? In Haskell zorgt het type system er voor dat acties met side effects (het impure gedeelte) netjes gescheiden wordt van het puur functionele. Een leesactie van de schijf geeft bijvoorbeeld een IO String terug, niet een String.

[Electrowolf]

Mee eens, code in imperatieve talen, en vooral oo talen, is makkelijker om te schrijven naar multi threaded dan functionele talen.

Een functionele taal haalt zijn kracht juist uit het kunnen analyseren wat wel en wat niet moet worden uitgerekend. Als je dit op gaat splitsen zal hoeveelheid rekenwerk dat kan worden overgeslagen waarschijnlijk verminderen. En zoals in de slides die RayNBow linkte wordt gemeld, code die niet van te voren is geschreven met in gedachte dat het parralel moet worden is niet even 123 om te schrijven. (Interesting slides btw)

In imperatieve talen wordt alles uitgerekend en hoef je niet "beter" naar je code te kijken en kan je dus makkelijk deelberekeningen parralel naast elkaar laten draaien. Door bijvoorbeeld , in java, een paar monitors toe te voegen heb je dit redelijk snel voor elkaar. Dit is natuurlijk niet meteen optimaal, maar je kan al een leuk deel paralelliseren.

[kw4h]

Ik denk niet dat als we meer cores krijgen we verplicht zijn om ze allemaal te gaan opbruiken. Persoonlijk denk ik dat het aantal Threads dat je maakt nog steeds word bepaald door je applicatie, en niet door je aantal cpu-cores.

Ik vraag me dan ook af of het 'automatisch' detecteren van multithreaden gaat werken. Een programmeur zou namelijk misschien een stukje code apart in een thread willen laten uitvoeren dat niet binnen de standaarden van hoe normaal Threads gebruikt moeten worden. Ik heb toch liever zelf de vrijheid dan dat er voor mij gedacht wordt.

[graey]

En daarom zullen er wel verschillende talen blijven, en verschillende manieren om multithreading aan te pakken Het één sluit het ander niet uit .

[vmsw]

Met de huidige vooruitgang van de hoeveelheid cores is het wel belangrijk dat veel meer programmeurs gebruik gaan maken van deze mogelijkheden. Het denken dat je hierbij moet toepassen is betrekkelijk nieuw; mensen denken meestal aan één ding, en dus bij de computer moet je opeens op een heel andere manier gaan denken. Dit komt natuurlijk het werken ermee niet ten goede.
Zouden vrouwen een voorsprong hebben?

Wel mooi dat er zo'n programma verschijnt, om het te strimuleren. Want bijna iedereen heeft al dual core, of regelmatig triple/quadcore: dit moet dan wel gebruikt worden vind ik; want op dit moment is een snelle core2duo beter dan een iets tragere quadcore, gewoonweg omdat de programma's nog niet ontwikkeld zijn.
En het is natuurlijk wel jammer om een betere processor te laten liggen omdat de programma's nog niet zo ver zijn: het is mooier om direct iets goeds te kopen, en zo snel te beginnen en blijven werken.

Dat het alleen voor java is, is niet zo heel erg. Dit is een begin, en de kans dat andere programma's (à la dit programma) verschijnen voor bijv. C is aanwezig: ik verwacht dat deze niet lang op zich laten wachten. Zodra het er is, ga ik het proberen te gebruiken... lijkt me geweldig!

[Reactie gewijzigd door vmsw op 28 juli 2024 22:39]

[epic007]

Om optimaal gebruik te maken van de mogelijkheden van moderne multicoreprocessors moet een softwareontwikkelaar gebruik maken van meerdere threads in zijn programma.

Om optimaal gebruik te maken van de mogelijkheden van moderne multicoreprocessors moet je mijn inziens geen JAVA gebruiken.

[kiang]

idd, want de JVm werkt op je echte machine (dus niet de VM, die ondersteunt meerdere threads) in slecht 1 thread...

[Verwijderd]

Je lijkt de begrippen thread (draad) en process (proces) door elkaar heen te halen. Het is inderdaad zo dat de JVM op het OS slechts 1 process in beslag neemt, maar daaruit kun je niet besluiten dat het slechts op 1 processor draait: een process kan steeds uit meerdere threads bestaan, en die threads kunnen wel degelijk op verschillende processoren in uitvoering zijn - dat hangt af van de scheduler van het OS. De JVM kan dus wel degelijk overweg met meerdere cores.

Dat Java geen optimaal gebruik maakt van moderne multicoreprocessors kun je allicht op andere manieren beargumenteren, maar hoe "lager" je bij de hardware programmeert, hoe complexer zaken worden, hoe meer fouten je code zal bevatten en vooral hoe hoger je time-to-market zijn (en dus ook je kosten).

[kiang]

Ik haal helemaal geen begrippen door elkaar, ik heb het gewoon fout blijkbaar. Ik dacht da de JVM single-Threaded was, over processen heb ik nooit iets gezegd.

verder hoef je me niet te vertellen dat dingen complexer worden wanneer je dichter bij de hardware komt: tegenwoordig moet ik voor mn opleiding namelijk in assemblercode werken...

[Reactie gewijzigd door kiang op 28 juli 2024 22:39]

[Remus]

Vroegah, toen Java net uit was, was het op sommige platformen (volgens mij alleen Solaris), waarbij Java-threads gemultiplexed werden op een enkele OS-thread, daar is volgens mij al in 1.1 of 1.2 al vanaf gestapt (al mag geloof ik een VM implementatie er nog steeds voor kiezen om het zo te implementeren, niemand doet dat)

[SPee]

Ik meen mij te herinneren dat Java voor de oude DOS versie, intern zo in elkaar zat dat je toch gebruik kon maken van meerdere Threads, ookal ondersteunde je OS dat niet.
Voor zover ik weet draaid b.v. de Gabage Collector in een aparte Thread.

[Gerco]

Onzin.

De VM kan op een degelijk besturingssysteem (waar ook Windows Server onder valt) gewoon meerdere OS-thread gebruiken (en doet dat ook). Met een Java programma kun je ook onder Windows XP gewoon meerdere cores volop belasten. Als je dat niet doet, zit je programma gewoon brak in elkaar. Dat heeft niets met Java als platform te maken.

[JaWSnl]

Voor iemand die meer wil weten over mogelijke problemen die multithreading met zich mee brengt en hoe dit opgelost kan worden, is er het Dining Philosophers probleem bedacht.

http://en.wikipedia.org/wiki/Dining_philosophers_problem

Zeker interessant! Er zijn nog meer van dit soort problemen bedacht waarvan er enkele verwijzingen ook staan op wikipedia.

[merethan]

Sinds ~1985 is het vooruitstrevende Ericsson lab al bezig met een rete goeie multi-threaded taal en runtime enviroment. Ontworpen voor massieve parralelle verwerking en zero downtime door redundantie. Schaalbaar van een enkele desktop PC naar meerdere supercomputers. Erlang heeft al tijden een enorme voorsprong op enig andere taal.

http://www.erlang.org/

[Freeaqingme]

Nu programmeer ik eigenlijk alleen maar in php, en heb zodoende weinig tot geen ervaring met multithreaded programmeren. Uit het artikel begrijp ik dat deze software kan helpen je multithreaded applicaties stabieler te maken (het voorkomen van Race conditions of Deadlocks). In de titel wordt gesuggereerd dat deze software ook je applicaties veiliger maakt, maar in welk opzicht is een Race Condition of Deadlock onveilig?

[JaWSnl]

Deadlock kan ervoor zorgen dat 2 threads beiden wachten op het gebruik van een gedeelde variabele, die de ander op dat moment gelockt heeft. Dus stel je voor dat je hebt:

Thread 1 & 2 - Variabele A & B
Beide threads mogen beide variabele gebruiken maar niet tegelijk.

Thread 1 gaat in een exclusieve "Lock" om variabele A aan te passen, en in die gelockte sectie moet een variabele B beschreven worden, en moet dus een gelockte sectie aanvragen voor het aanpassen variabele B.
Thread 2 heeft precies het omgekeerde en is bezig met Variabele B en heeft variabele A nodig die op dit moment gelockt wordt door Thread 1.

Resultaat: Beide threads wachten op elkaar en lijden zo aan Deadlock.

Dit kan soms erg lastig voorkomen worden en moet specifiek per probleem worden opgelost.


Race Condition kan gevaarlijk zijn wanneer 2 threads tegelijk een variabele willen ophogen. Tijdens dit ophogen wordt bv. gebruik gemaakt van een aparte plaats in het geheugen als tussenstap, waarin de oude waarde wordt gezet en waar 1 bij wordt opgeteld, waarna hij wordt weggeschreven naar de variabele. Als de 2e thread nu de variabele gaat ophogen terwijl thread 1 nog in het register aan het werken is, zal de 2e thread de oude waarde zien en de output nog steeds maar 1 omhoog gaan terwijl het +2 had moeten zijn.

Resultaat: Thread 1 maakt de beginwaarde + 1, maar thread 2 maakt ook de beginwaarde + 1, ook al heeft thread 1 die waarde net al in de variabele gezet.

edit: oplossing voor Race Condition is dus een Critical Section waarin elk proces eerst moet komen voor het iets met de variabele mag doen. Er kan maar 1 thread tegelijk in een critical section.

[Reactie gewijzigd door JaWSnl op 28 juli 2024 22:39]

[Verwijderd]

Een race condition is eigenlijk een geval waarin de uitkomst van een functie (of een stuk code) door gebrekkige parallelisatie niet met zekerheid vastgesteld kan worden.

Voorbeeld (let wel, dit is expres een 'bad practice'):

een functie maakt gebruik van een globale variabele 'X' die hij met tussenpozen (zeg elke halve seconde) bekijkt en een stuk code uitvoert als deze waarde bijv. 10 is. Tegelijkertijd is er een andere thread die waarde 'X' ook gebruikt, namelijk door hem elke seconde op te hogen.
Theoretisch zou je verwachten dat het stukje code achter conditie X==10 altijd uitgevoerd zal worden. Maar is er geen enkele garantie dat de eerste thread tijd gegund wordt om te executen gedurende de tijd dat de tweede thread 'X' op 10 heeft gezet. Het zal vaak voorkomen, maar de clou is dat de garantie er niet is. Dus kan het stukje code dat de eerste thread uitvoert bij X==10 wel of niet uitgevoerd worden, zonder dat duidelijk is waarom.
Het is dus een soort race tussen 'geval 1' (wel uitgevoerd) en 'geval 2' (niet uitgevoerd). Soms wint de een, soms de ander.

[.oisyn]

edit: oplossing voor Race Condition is dus een Critical Section waarin elk proces eerst moet komen voor het iets met de variabele mag doen. Er kan maar 1 thread tegelijk in een critical section.

En overvloedig gebruik van mutual exclusion is weer een recept voor deadlocks. In feite wil je zoveel mogelijk lockless programmeren. Zo ondersteunen de meeste platforms wel atomische geheugen-operaties zodat een thread bijvoorbeeld een waarde kan ophogen zonder dat een andere thread tegelijk iets met dat geheugen kan doen (in feite is het dan de memory controller of aanverwante hardware die voor de mutual exclusion van dat stukje geheugen zorgt). Helaas is goed lockless programmeren verre van triviaal en zijn het juist de race conditions waar je goed voor uit moet kijken. Gelukkig zijn er ook lockless containers voor allerlei talen en platforms die zich al bewezen hebben en waarvoor je het wiel dus niet meer opnieuw uit hoeft te vinden .

[Freeaqingme]

Ty, da's duidelijk

Maar waardoor is dit dan onveilig?

[JaWSnl]

Tjah door deadlock: een programma doet niks meer want threads (geen processen, goed opgelet dank u graey) wachten op elkaar om verder te kunnen.

edit: en door race condition worden waarden niet meer wat ze hadden moeten zijn met logischer wijs lastige gevolgen.

[Reactie gewijzigd door JaWSnl op 28 juli 2024 22:39]

[graey]

Processen of threads?

[Verwijderd]

threads

[kiang]

onveilig, niet als in "all your PC belong to us" maar als in dat het programma niet sabiel loopt en vastloopt Da is volgens mij toch waarover jij het hebt, niet?

[Reactie gewijzigd door kiang op 28 juli 2024 22:39]

[darkfader]

Niet echt onveilig als in direct exploitbare code, maar in situaties waarin je liever niet hebt dat de software hangt of uit z'n voegen loopt.

[Daimanta]

Het schrijven van verkeerde waarden is sommige situaties levensgevaarlijk. Zo kan een apparaat een verkeerde meting doen en zo verkeerde waarden doorgeven. Dit heeft geleid toto 3 doden bij een medisch apparaat en een reusachtige stroomuitval in de VS.

Zie Wikipedia:

http://en.wikipedia.org/wiki/Race_condition

[PolarBear]

Volgens mij is de titel wat algemeen. Alleen Java wordt ondersteund. Dus geen C#, C, C++ enz.

[Verwijderd]

Inderdaad, ik hoop dat dit ook voor C# gemaakt gaat worden, heeft toch mijn voorkeur met programmeren

[dtech]

C# heeft al hele goede threading opties. Ik denk dus niet dat er snel iets voor beschikbaar zal komen.
Overigens kun je die functies vanuit alle talen benaderen, als je tenminste het .NET framework gebruikt. (Dus als je MS tools wilt gebruiken: C#, C++ en VB.NET, voor Phyton, Perl, PHP en PHP zijn ook compilers beschikbaar)

[_Thanatos_]

C# heeft al hele goede threading opties

Haha, grapje zeker? Al eens ermee geprobeerd te werken? Het is een drama.
Je kunt bijvoorbeeld niet eens een thread de GUI laten updaten en vervolgens die thread joinen, dan heb je een deadlock te pakken. Ook is er geen goeie ingebouwde mogelijkheid om een thread af te breken (noch een hard abort, noch een soft abort). De voorziening die daarvoor bestaat, geeft teveel kans op deadlocks. Ohja, en een thread die eenmaal gestopt is, moet je helemaal opnieuw maken om em te herstarten. En pauze hebben ze eruit gesloopt

Nee, hele "goeie" opties hoor.

[latka]

Ik denk dat je de tool niet begrijpt: het hebben van threading opties is het probleem niet (die heeft Java ook en vergelijkbaar met C# niet beter, niet slechter). Alleen is het vrij moeilijk om goed gebruik te maken van de mogelijkheden. Vaak maak je het alleen maar slechter door incorrect gebruik van threads of het introduceren van bugs die alleen in multithreaded software zitten (o.a. race-condities & deadlocks). Hier helpt de tool dus bij.

[Laurens-R]

MS is nu bezig met het Parallels FX framework... het werkt een beetje als OpenMP (dus voor for loops e.d.)

Wellicht niet geschikt voor de mensen die echt weten hoe threading in elkaar steekt, maar handig genoeg om snel en simpel je app klaar te maken voor multicore.

[Verwijderd]

Het is nogal een specifiek aan een taal of VM platform gebonden. Het zal onwaarschijnlijk zijn dat er 1 tool zal komen die alle populaire talen zal ondersteunen. Als je dit voor C++ wilt hebben dan kan je meer vinden op de Intel website:

[Bram_S]

Er is ook nog een vrij open source programma beschikbaar dat ook race condities checkt: helgrind. Dit is onderdeel van Valgrind (http://valgrind.org). En dat bestaat al een tijdje dus ik vind dit artikel niet bijzonder veel nieuwswaarde hebben.

[Reactie gewijzigd door Bram_S op 28 juli 2024 22:39]

[JaWSnl]

het heeft veel nieuwswaarde omdat ik er nog niet van had gehoord. Maar jouw informatie is zeker interessant

[Havocnl]

Dit soort thread help technieken zijn er al een aantal jaar nu. Intel heeft onder andere een threading toolkit voor developers gemaakt waardoor ze tijdens het programmeren niet meer druk hoeven maken om threads. En zo zijn er nog een aantal oplossingen te vinden.

Conclusie:
Een goed zoekende developer kan voor mulit-threading developen een berg aan tools vinden van allemaal gerespecteerde ontwikkelaar

[_Erikje_]

Dan kan je bijna elk nieuwsbericht wel als reclame zien. Dit is gewoon een leuke ontwikkeling voor java engineers

[JaWSnl]

Ja inderdaad dit is gewoon een handige tool die ik ook graag voor C en C++ had gezien wat nu dus niet het geval is. Recent begonnen met multithreaded programmeren en er komt nog aardig wat bij kijken, goed opletten dus... dit zou het een stuk makkelijker maken, maar wss is het niet/verre van gratis, kan helaas niet vinden hoeveel.

maar wie weet wat de toekomst voor ons in petto houdt

[kiang]

C en C++ zijn origineel gezien dan ook single-threaded talen, en slecht multi-threaded te maken op een zeer archaïsche manier, wat volgens mij het maken van een dergelijk tool ook niet makkelijker maakt

[jjkewl]

Mag je mij uitleggen waarom Java daar wel geschikt voor is, mijn kennis van Java schiet daarbij te kort. Multithreading is mijn ogen een uitdaging voor elke taal. Het is imho dan ook meer een high level probleem dan een taal probleem. Of vertrouw je blind je compiler? Ik heb het nog niet zelf, als voornamelijk c++'er, aan de tand kunnen voelen of het daadwerkelijk de lading dekt of dat het open deur problemen signaleerd. Iig goede ontwikkeling nu multi cpu gangbaar geworden is.

[kiang]

Java is van het beginuit gemaakt om mltithreading te ondersteunen: sinds JDK 1.0 is de klasse Thread beschikbaar, waardoor je, om een nieuwe Thread te maken, nog maar slecht iets als Runnable moet imlementeren, en je kan direct een heel process in je programma op een andere Thread steken.

Natuurlijk moet je opletten voor deadlocks en alle standaardproblemen met threads, maar ik bedoel maar dat Java standaard meerdere threads ondersteund en er al een handige API voor aanbiedt, terwijl C en C++ dit helemaal niet doen.

[Verwijderd]

De POSIX threads library is redelijk standaard inmiddels.

http://www.yolinux.com/TU...TutorialPosixThreads.html

Op Linux/Unix/BSD systemen kost het je slechts een paar configuratieregels (AC_CHECK_LIB en wat #ifdef-s) om deze functionaliteit beschikbaar te hebben.

Verder is het in Java helemaal niet makkelijker of moeilijker. Multithreading is een onderwerp waar alleen ervaren programmeurs goed mee om kunnen gaan, juist omdat ze het allemaal weleens voor elkaar krijgen om de boel in de soep te laten lopen. De taal of het plafform maken niet veel uit, het is een universeel principe.

[ATS]

Dat soort ondersteuning zit niet standaard op een handige manier in de libs nee, maar er zijn uitstekende libs die dit wél bieden. Zo heeft de Qt toolkit een uistekende set tools voor threading, waarmee je dus zowel in c++, maar ook in python of java prima multi threaded programma's kan maken. Dat wil echter niet zeggen dat dit soort tools niet nodig of nuttig zijn. Je kan jezelf nog prima ophangen met deadlocks en dat soort dingen...

[JaWSnl]

Wat een onzin dit is puur informatief en zeker heel erg handig om te weten voor een boel tweakers. Dit is net zo min reclame als de nieuwsberichten over bijvoorbeeld GTA IV of een ander gelanceerd product.

Persoonlijk vind ik het erg interessant, nu nog wachten op het "reclame"-bericht over de release van een C++ variant.

[Reactie gewijzigd door JaWSnl op 28 juli 2024 22:39]