[Java] niet loopende Thread suspenden/resumen

[Robtimus]

Ik heb een aantal Threads zonder loop, dus niet met

Java:

public void run()
{
    while (condition)
    {
        // body
    }
}

maar met

Java:

public void run()
{
    // body zonder while (condition)
}

Nu moet ik deze Threads gaan suspenden en later weer resumen. Gebruik maken van de deprecated suspend en resume methods van Thread kan niet omdat in de body een synchronized block zit. Bij een suspend wordt deze niet gereleased en dus kan er deadlock ontstaan. De oplossingen die in de Java API worden gegeven werken alleen met een while loop.

Nu had ik het idee om misschien toch de suspend en resume te gaan gebruiken, maar deze dan aanroepen in een synchronized block op hetzelfde object. De suspend/resume kan dan niet aangeroepen worden zolang een thread in zijn eigen synchronized block zit. Op papier moet dit werken, maar ik vind het geen nette oplossing, oa omdat ik dan gebruik moet maken van deprecated methods.

Weet iemand een betere oplossing?

[GarBaGe]

Kan je in jouw geval niet beter de Thread laten "afsterven" en later opnieuw starten indien nodig ??
Of een blocking call oid ??
Het is immers niet voor niets dat suspend en resume tegenwoordig eigenlijk niet meer gebruikt mogen worden. Het werkelijk stoppen van een thread is veel te gevaarlijk ivm deadlocks...

[Robtimus]

GarBaGe schreef op 20 januari 2004 @ 10:08:
Kan je in jouw geval niet beter de Thread laten "afsterven" en later opnieuw starten indien nodig ??
Of een blocking call oid ??
Het is immers niet voor niets dat suspend en resume tegenwoordig eigenlijk niet meer gebruikt mogen worden. Het werkelijk stoppen van een thread is veel te gevaarlijk ivm deadlocks...

Laten afsterven is denk ik geen optie, want hoe begin ik dan weer midden in mijn code? En idem met blocking call, waar plaats ik die call? Na elk statement?? Dat is juist het probleem, er is geen punt dat steeds weer uitgevoerd wordt, anders was het een stuk eenvoudiger.

[Verwijderd]

Als je op de api van java op de sun site kijkt java.sun.com, kun je bij de depracted functie vaak een link vinden met daarin een oplossing beschreven hoe een soort gelijke constructie kan worden gemaakt, die de functionaliteit van de deprecated functie kan vervangen...

* Nu kan ik ff die linkjes zoeken, of verder gaan met werken.. em *

http://java.sun.com/docs/...t1.0/preview/threads.html
over veranderingen in de thread klasse (oa supsend en resume)
http://java.sun.com/j2se/...PrimitiveDeprecation.html
nog zo pagina
http://onesearch.sun.com/...dex.jsp?qt=thread.suspend
zoekactie op java site (kijk maar of er nog meer mug tussen zit die je kan helpen

Veel succes

[Robtimus]

Verwijderd schreef op 20 januari 2004 @ 11:16:
Als je op de api van java op de sun site kijkt java.sun.com, kun je bij de depracted functie vaak een link vinden met daarin een oplossing beschreven hoe een soort gelijke constructie kan worden gemaakt, die de functionaliteit van de deprecated functie kan vervangen...

* Nu kan ik ff die linkjes zoeken, of verder gaan met werken.. em *

http://java.sun.com/docs/...t1.0/preview/threads.html
over veranderingen in de thread klasse (oa supsend en resume)
http://java.sun.com/j2se/...PrimitiveDeprecation.html
nog zo pagina
http://onesearch.sun.com/...dex.jsp?qt=thread.suspend
zoekactie op java site (kijk maar of er nog meer mug tussen zit die je kan helpen

Veel succes

Die eerste 2 had ik al doorgekeken, maar die leggen alleen uit hoe het gaat als je een loop in je run hebt. Dat is juist het probleem, die is er niet. Maar ik zal es naar die andere kijken.

Edit: niet dus. Van de 22 results verwijst het overgrote deel naar de API pagina's van Thread, ThreadGroup en hun excepties. De rest verwijst naar het verhaaltje over waarom ze deprecated zijn en hoe het op te lossen voor run methods met een loop of over virtual machines, maar geen oplossing voor mijn probleem,

[ Voor 13% gewijzigd door Robtimus op 20-01-2004 13:56 ]

[Verwijderd]

IceManX schreef op 20 januari 2004 @ 13:51:
[...]
Die eerste 2 had ik al doorgekeken, maar die leggen alleen uit hoe het gaat als je een loop in je run hebt. Dat is juist het probleem, die is er niet. Maar ik zal es naar die andere kijken.

Edit: niet dus. Van de 22 results verwijst het overgrote deel naar de API pagina's van Thread, ThreadGroup en hun excepties. De rest verwijst naar het verhaaltje over waarom ze deprecated zijn en hoe het op te lossen voor run methods met een loop of over virtual machines, maar geen oplossing voor mijn probleem,

Misschien zou je dan eens moeten kijken naar het ontwerp van je programma (ik snap nog steeds niet goed waarom je perse een constructie gebruikt waarbij je die suspend / resume eigenlijk nodig hebt, en het niet op een andere manier oplost. Dit kan ik ook niet terug vinden in je startpost). Sun maakt die functies niet voor niets deprecated. De kans dat jij een thread suspend die vervolgens nooit meer wordt geresumed is aanwezig. Dit soort constructies kan, geheugenproblemen en deadlocks veroorzaken. Dit zijn geen eigenschappen van een solide / robuust ontwerp.

Zou je misschien wat meer info kunnen geven, over je app (en waarom je perse die constructie wilt gebruiken), dan kunnen we ff wa beter meedenken

[ Voor 3% gewijzigd door Verwijderd op 20-01-2004 14:12 . Reden: Onduidelijkheidje weggehaald ]

[Robtimus]

Ik ben bezig een earliest deadline first scheduler van taken te maken, waarbij taken dus gepre-empt moeten kunnen worden.
Ik had er ook al aan gedacht om de prioriteiten van de threads te veranderen, zodat de thread met de hoogste prioriteit altijd runt. Ipv een thread suspenden verlaag ik dan zijn prioriteit, en een resume is de prioriteit weer verhogen. Helaas werkt dat niet altijd even perfect heb ik gezien Bij een test van me gingen threads draaien die het gezien hun prioriteit (die ik dynamisch veranderde) nooit mochten doen.

[Verwijderd]

IceManX schreef op 20 januari 2004 @ 14:31:
Ik ben bezig een earliest deadline first scheduler van taken te maken, waarbij taken dus gepre-empt moeten kunnen worden.
Ik had er ook al aan gedacht om de prioriteiten van de threads te veranderen, zodat de thread met de hoogste prioriteit altijd runt. Ipv een thread suspenden verlaag ik dan zijn prioriteit, en een resume is de prioriteit weer verhogen. Helaas werkt dat niet altijd even perfect heb ik gezien Bij een test van me gingen threads draaien die het gezien hun prioriteit (die ik dynamisch veranderde) nooit mochten doen.

?earliest deadline first scheduler? ik neem aan de thread die het snelst af moet zijn wordt als eerst gescheduled? hoe wordt die "first deadline" bepaald?

Het gaat dus om het schedulen van een groepje thread (hoeveel max, min?). Weet ook niet uberveel van java threads af (iig niet als het op schedulen gaat), maar als je die bende threads in een ThreadGroup gooit misschien dat die priority dan wel fatsoenlijk werkt?

Heb ook ff weer gezocht op thread priority (het gaat hierbij dan weer wel om thread met while() { //body } constructie):
http://java.sun.com/docs/...ial/threads/priority.html

Nog wa tutorial info over de ThreadGroup:
http://java.sun.com/docs/...ential/threads/group.html


Update #1
========
Heb ff die eerste link zitten doorlezen daarin zit een "Rule of thumb":

-----------------------------------------------------------------
Rule of thumb: At any given time, the highest priority thread is running. However, this is not guaranteed. The thread scheduler may choose to run a lower priority thread to avoid starvation. For this reason, use priority only to affect scheduling policy for efficiency purposes. Do not rely on thread priority for algorithm correctness.
------------------------------------------------------------------

Zoals je begrijpt zal het prioriteitenfeest dus niet werken

Veel succes weer

[ Voor 20% gewijzigd door Verwijderd op 20-01-2004 14:58 . Reden: update#1 ]

[Robtimus]

Verwijderd schreef op 20 januari 2004 @ 14:46:
?earliest deadline first scheduler? ik neem aan de thread die het snelst af moet zijn wordt als eerst gescheduled? hoe wordt die "first deadline" bepaald?

Goed begrepen. Deadlines ga ik denk ik absoluut doen, die worden iig wel opgegeven. First Deadline is dus de deadline die het dichtst bij nu is.

Het gaat dus om het schedulen van een groepje thread (hoeveel max, min?). Weet ook niet uberveel van java threads af (iig niet als het op schedulen gaat), maar als je die bende threads in een ThreadGroup gooit misschien dat die priority dan wel fatsoenlijk werkt?

Aantal moet in principe onbegrensd zijn, al zal het van de praktijk afhangen. Maar ik zal idd eens kijken of het wel werkt in een ThreadGroup.

Heb ook ff weer gezocht op thread priority (het gaat hierbij dan weer wel om thread met while() { //body } constructie):
http://java.sun.com/docs/...ial/threads/priority.html

Nog wa tutorial info over de ThreadGroup:
http://java.sun.com/docs/...ential/threads/group.html

Die tutorials heb ik hier op mijn HD staan, die raadpleeg ik regelmatig

Update #1
========
Heb ff die eerste link zitten doorlezen daarin zit een "Rule of thumb":

[...]

Zoals je begrijpt zal het prioriteitenfeest dus niet werken

Veel succes weer

Damn, daar ben ik niet blij mee. Ik zal dan eens kijken of het real-time OS waar ik het op ga draaien (ik weet nog niet precies welke) zich houdt aan die Rule Of thumb, Windows 2000 iig niet.

[packman]

Je hele logic synchronized maken in een thread doet men normaalgezien toch niet vind ik. Dit is om problemen vragen vind ik. Wat je normaalgezien doet is de delen die echt synchronized moeten gebeuren (wijzigen/access van shared variabelen o.a.) in een eigen synchronized method steken, maar toch niet je hele logic binnen een thread?

[Verwijderd]

IceManX schreef op 20 januari 2004 @ 15:03:

Damn, daar ben ik niet blij mee. Ik zal dan eens kijken of het real-time OS waar ik het op ga draaien (ik weet nog niet precies welke) zich houdt aan die Rule Of thumb, Windows 2000 iig niet.

Volgens mij is een deel van je probleem (maar daar ben ik niet scheduleguru genoeg voor om dat echt te bepalen), dat je iig al 2 schedulers onder jou eigen scheduler hebt (die van je OS (is ook al preemtive) en die van je VM (ook preemtive). Daar bovenop wil je ook nog je eigen scheduler gebruiken. Dan kun je volgens mij niet gebruik maken van de schedule technieken die de Thread objecten binnen Java aanbiedt [oa. priority] (want die heeft dus al een eigen scheduler in dienst ). Ookal heb je een realtime OS. Java staat daarboven. Java biedt iets aan je CPU aan en die zal het (afhankelijk van je OS) zelf weer gaan schedulen, als Java dan weer iets anders in scheduled zal ie dat weer aan je OS aanbieden die het dan vervolgens ook weer scheduled enz, enz.

Je moet dus zelf echt bepalen of een thread moet stoppen en door mag. Waarom je perse een thread zonder while wilt gebruik weet ik niet (nou waarom? ). Aangezien de enige twee echte operaties deprecated zijn (weet niet of ze deprecated zijn in de zin van: "over 2 versies bestaan ze nie meer want het is brakke code" of "we maken ze maar deprecated om aan te geven dat die functies gevaarlijk zijn voor prutsende programmeurs").
Meegenomen dat jij je eigen scheduler aan het schrijven bent en waarschijnlijk wel goed zorgt dat threads niet uitsterven, in een deadlock raken of voor altijd lekker blijven slapen, kun je, als het om reden nummer 2 depracted functies zijn, ze toch wel gebruiken (hoe je erachter komt wat de reden is, is nog maar de vraag).

Neem aan dat een andere progtaal (C, C++) niet tot de opties behoren? Realtime Linux in combinatie met de aangepaste POSIX threads die RTLinux biedt, zou de uitkomst zijn voor jou probleem.

Maar nog 1 essentieel vraagje? Waarom ben je die scheduler aan het schrijven, Java en het OS doen toch ook al een goede zaak? Of staat de app los van het uitvoeren van systeemtaken?

Veel succes

[ Voor 1% gewijzigd door Verwijderd op 20-01-2004 15:31 . Reden: tiepvaut ]

[Robtimus]

packman schreef op 20 januari 2004 @ 15:24:
Je hele logic synchronized maken in een thread doet men normaalgezien toch niet vind ik. Dit is om problemen vragen vind ik. Wat je normaalgezien doet is de delen die echt synchronized moeten gebeuren (wijzigen/access van shared variabelen o.a.) in een eigen synchronized method steken, maar toch niet je hele logic binnen een thread?

Mijn hele logic is niet synchronized, alleen de access tot mijn (shared) dataruimte. Verder runt de hele logic wel in een thread, maar nog zonder synchronisatie.

Verwijderd schreef op 20 januari 2004 @ 15:30:
[...]


Volgens mij is een deel van je probleem (maar daar ben ik niet scheduleguru genoeg voor om dat echt te bepalen), dat je iig al 2 schedulers onder jou eigen scheduler hebt (die van je OS (is ook al preemtive) en die van je VM (ook preemtive). Daar bovenop wil je ook nog je eigen scheduler gebruiken. Dan kun je volgens mij niet gebruik maken van de schedule technieken die de Thread objecten binnen Java aanbiedt [oa. priority] (want die heeft dus al een eigen scheduler in dienst ). Ookal heb je een realtime OS. Java staat daarboven. Java biedt iets aan je CPU aan en die zal het (afhankelijk van je OS) zelf weer gaan schedulen, als Java dan weer iets anders in scheduled zal ie dat weer aan je OS aanbieden die het dan vervolgens ook weer scheduled enz, enz.

Ja, daar ben ik ook al achter. Net mijn testprogrammaatje dat priorities test en wisselt getest op een RTOS, en die doet het goed... alleen verkeerd om, de thread met de laagste prio runt steeds

Je moet dus zelf echt bepalen of een thread moet stoppen en door mag. Waarom je perse een thread zonder while wilt gebruik weet ik niet (nou waarom? ). Aangezien de enige twee echte operaties deprecated zijn (weet niet of ze deprecated zijn in de zin van: "over 2 versies bestaan ze nie meer want het is brakke code" of "we maken ze maar deprecated om aan te geven dat die functies gevaarlijk zijn voor prutsende programmeurs").

Die thread is een control flow, iets dat sequenteel uitgevoerd moet worden, niet iets dat herhaaldelijk moet gebeuren. Ik stop het in een thread omdat het wel parallel met andere threads moet lopen, en ook eventueel gepreempt moet worden.

Meegenomen dat jij je eigen scheduler aan het schrijven bent en waarschijnlijk wel goed zorgt dat threads niet uitsterven, in een deadlock raken of voor altijd lekker blijven slapen, kun je, als het om reden nummer 2 depracted functies zijn, ze toch wel gebruiken (hoe je erachter komt wat de reden is, is nog maar de vraag).

Ik denk dat het om reden 2 is gebeurd, want ik krijg het gevoel dat Java dingen zelden tot nooit verwijdert, wegens backwards compatibility. Hoe dan ook kan ik eisen voor mijn implementatie (is voor mijn afstudeeropdracht) dat het alleen in JVM 1.4 mag draaien.

Neem aan dat een andere progtaal (C, C++) niet tot de opties behoren? Realtime Linux in combinatie met de aangepaste POSIX threads die RTLinux biedt, zou de uitkomst zijn voor jou probleem.

Mijn werk is gebaseerd op een implementatie in Java. Daar komt bij dat ik een heel stuk bekender ben met Java dan met C(++). Maar als het echt niet anders kan bestaat er ook nog altijd de mogelijkheid die JNI me biedt. Alleen gezien mijn kennis van JNI en C(++) is dat niet echt aan te bevelen...

Maar nog 1 essentieel vraagje? Waarom ben je die scheduler aan het schrijven, Java en het OS doen toch ook al een goede zaak? Of staat de app los van het uitvoeren van systeemtaken?

De Java scheduler is geen optie, die maakt alleen gebruik van priorities, en niet eens 100% correct (starvation tegen gaan). Blijft over de scheduler van het OS, maar 1) ik wil het zo platform onafhankelijk maken, en 2) ik ben niet bekend met JNI, dus ik weet niet goed hoe ik het OS moet aanspreken. Zoals al gezegd een laatste redmiddel.

Veel succes

Dank je

Ik ga dan denk ik voorlopig eerst maar met suspend en resume proberen, en anders de moeilijke manier...

* Robtimus ziet nu pas dat de titel verkeerd is, had moeten zijn niet-lOOpende... ach ja