Prioriteren van Messages in een MessageQueue v/e Thread

[redesign]

Vraagje...

Is het mogelijk om een MessageQueue van een Thread te prioriseren aan de hand van het type bericht of berichten die in de MessageQueue worden ontvangen (op het moment dat een nieuw bericht is ontvangen)?

Voorbeeld:
In de MessageQueue komen messages binnen in deze volgorde: MsgType_B, MsgType_C en MsgType_D. Deze messages dienen gesorteerd te worden in volgorde zodat deze berichten verder verwerkt kunnen worden door een andere Thread (binaire verzending van gegevens). De nieuwe volgorde is MsgType_C, MsgType_D, MsgType_B (waarbij C als eerste en D als laatste verwerkt worden).
Terwijl en nog messages in de queue staan kan er nog een MsgType_A binnenkomen die als eerste verstuurt dient te worden. Dus wanneer MsgType_C als eerste in de queue voorkomt maar nog niet verwerkt wordt, dan dient MsgType_A nog vóór MsgType_C geplaatst te worden.

Ik heb geen invloed op de binnenkomst van de berichten aangezien deze vanuit meerdere bronnen willekeurig binnen kunnen komen op de MessageQueue van deze Thread.

Ik gebruik geen service bus of third party message queue libraries, allemaal overbodig. Laten we het vooral simpel houden

Vraag: Hoe kan ik een MessageQueue sorteren, of nog beter - en zonder telkens te hoeven sorteren - de belangrijkste berichten vooraan in de queue zetten?

Graag jullie adviezen...

[IceM]

Ik weet niet of ik je helemaal goed begrijp omdat je geen specifieke message queue implementatie of taal noemt, maar volgens mij wil je gebruik maken van een priority queue?

[ Voor 4% gewijzigd door IceM op 16-10-2013 13:55 ]

[EddoH]

Ik zou binnen je MessageQueue abstractie meerdere queues maken voor elke priority en de queue met de hoogste priority steeds als eerste behandelen, dan de volgende, etc.

[ Voor 81% gewijzigd door EddoH op 16-10-2013 14:08 ]

[redesign]

IceM schreef op woensdag 16 oktober 2013 @ 13:55:
Ik weet niet of ik je helemaal goed begrijp omdat je geen specifieke message queue implementatie of taal noemt, maar volgens mij wil je gebruik maken van een priority queue?

Vergeten te vermelden: Java is de implementatie taal. Besturingssysteem is Android.

PriorityQueue klinkt goed, maar hoe weet ik nu dat de berichten gesorteerd worden bij binnenkomst de queue? Betekent dit dat ik in een bericht (message) een comparator moet implementeren? Hoe weet de PriorityQueue dan welke als eerste en welke als laatste verwerkt moet worden? Of kan ik dat ook in de PriorityQueue aangeven adhv de msg.what code?

Misschien overbodig om te vermelden, maar ik heb het idee dat ik e.e.a. door elkaar haal, zoals deze:
- MessageQueue: http://developer.android....roid/os/MessageQueue.html
- HandlerThread: http://developer.android....oid/os/HandlerThread.html
- Handler: http://developer.android....e/android/os/Handler.html
- Looper: http://developer.android....ce/android/os/Looper.html
- Messenger: http://developer.android....android/os/Messenger.html

Is een Messenger message hetzelfde als een Thread message?
Volgens mij moet nog even langer puzzelen...

[redesign]

EddoH schreef op woensdag 16 oktober 2013 @ 14:08:
Ik zou binnen je MessageQueue abstractie meerdere queues maken voor elke priority en de queue met de hoogste priority steeds als eerste behandelen, dan de volgende, etc.

Ik zit er inderdaad aan te denken om twee queues te maken: eentje voor B, C en D berichten en eentje voor A berichten. Op het moment dat dan het volgende bericht verwerkt dient te worden kijk ik naar beide queues om te bepalen welke als eerste "de deur uit moet": A of B/C/D?
Als ik hier voor kies dan heb ik wel weer een volgende vraag: hoe ontvang ik een message van een Thread in een andere queue? Moet ik daarvoor een Handler gebruiken die dan de inkomende berichten sorteert op type?

Andere vraag die mij nu te binnen schiet: als ik telkens Type_A berichten binnenkrijg, dan kom ik er niet meer aan toe om ook Type_B,C,D berichten te versturen... dat is ook weer niet de bedoeling. A moet "als eerste de deur uit" maar niet altijd ten koste van de andere messages. Misschien een tellertje gebruiken, nadat Type_A is verstuurd maximaal 10 berichten van Type_B/C/D?

Edit: typos

[Verwijderd]

redesign schreef op woensdag 16 oktober 2013 @ 13:50:
Vraag: Hoe kan ik een MessageQueue sorteren, of nog beter - en zonder telkens te hoeven sorteren - de belangrijkste berichten vooraan in de queue zetten?

Gebruik een max-heap of min-heap. In C++ heet dat een priority queue. Dit is een datastructuur welke altijd gesorteerd is en O( log( n ) ) insert en remove-max operaties kent.

Bescherm deze datastructuur met een mutex. Simpel genoeg?

[EddoH]

Het was me niet duidelijk dat je Android gebruikt en daar de bestaande message queue wilt gebruiken.

Volgens mij haal je een beetje Android MessageQueue en 'normale' Java queues door elkaar.
De Android MessageQueue gebruik je voor messaging van de ene naar andere thread (google even op voorbeelden van Messenger icm bijvoorbeeld een Handler).

Daarnaast wil je berichten gaan prioriseren. Volgens mij kan dit neit met de standaard MessageQueue in Android dus als alternatieft kun je dit doen voordat je ze in de MessageQueue stopt. Bijvoorbeeld door het gebruiken van een PriorityQueue voordat je ze in de MessageQueue stopt.
Je zou ook kunnen kijken of je zelf de Queue van de MessageQueue nog kan zetten, en hier dan een PriorityQueue voor gebruiken.

[ Voor 16% gewijzigd door EddoH op 16-10-2013 14:48 ]

[redesign]

EddoH schreef op woensdag 16 oktober 2013 @ 14:40:
Het was me niet duidelijk dat je Android gebruikt en daar de bestaande message queue wilt gebruiken.

Volgens mij haal je een beetje Android MessageQueues en 'normale' Java queues door elkaar.
De Android MessageQueue gebruik je voor messaging van de ene naar andere thread (google even op voorbeelden van Messenger icm bijvoorbeeld een Handler).

Daarnaast wil je berichten gaan prioriseren. Dit kun je doen voordat je ze in de MessageQueue stopt, of erna, bij het ontvangen. Bijvoorbeeld door het gebruiken van een PriorityQueue voordat je ze in de MessageQueue stopt.

Ik denk ook dat ik e.e.a. door elkaar haal, maar dat komt ook omdat ik e.e.a. door elkaar gebruik.

Ik ga vanuit een Android Activity naar een Android Service dmv een Android Messenger die een Message verstuurd. Vervolgens ga ik vanuit de Handler in de Android Service die op de main-Thread draait door naar een andere Thread (of meerdere Threads afhankelijk van de hardware). Ik wil afhankelijk van de Message die vanuit de Activity werd verstuurd bepalen welke Thread dit bericht in behandeling moet nemen.
Daarnaast heb ik ook Threads onderling die met elkaar "stoeien" over wie nu welk bericht dient te verwerken. Volgens mij haal ik IPC messages en Thread messages door elkaar

[EddoH]

Dan kun je toch gewoon voor elke Thread een aparte MessageQueue gebruiken en afhankelijk van het type bericht hem in de goede MessageQueue stoppen?

[redesign]

EddoH schreef op woensdag 16 oktober 2013 @ 14:49:
Dan kun je toch gewoon voor elke Thread een aparte MessageQueue gebruiken en afhankelijk van het type bericht hem in de goede MessageQueue stoppen?

Verklaar u nader...

Ik zat te denken aan een soort van overgangs mechanisme waarbij ik in de Android Service Handler de berichten laat "ontleden" in een aparte DispatcherThread (die dus naast de main Thread werkt) en vervolgens de berichen als Thread-message doorstuurt naar de juiste Thread die dan het echte werk doet. Die "worker" threads zijn dan de Threads die de MessageQueues beheren.
Volgens mij moet ik een overgangsmechanisme bouwen die een Messenger Message vertaalt naar Thread Message (waarbij de verstuurde objecten dan wel in worden meegegeven). En visa versa ook. Dus de DispatcherThread vertaalt ook de Thread Messages weer naar Messenger messages.

De droom is er, de ideeen ook, nu nog de implementatie.
De communicatie tussen Activity en Service dmv een Handler en Messenger heb ik werkend, nu nog het Threading gedeelte in de Service.

[EddoH]

Ik snap er werkelijk geen ene zak meer van

Messenger Message en Thread Message? Een Message is een Message in Android, geen idee waar dat verschil vandaan komt.

We kunnen je beter helpen als je je concrete probleem wat beter beschrijft in plaats van problemen met een theoretische implementatie

[Verwijderd]

EddoH schreef op woensdag 16 oktober 2013 @ 14:49:
Dan kun je toch gewoon voor elke Thread een aparte MessageQueue gebruiken en afhankelijk van het type bericht hem in de goede MessageQueue stoppen?

Volgens de topicstart heeft hij geen invloed op de messages die binnen komen bij het process. De messages zouden dus altijd bij de main thread terecht komen.

---

Waarom denk je eigenlijk een message priority nodig te hebben? Ik kan eigenlijk geen situatie bedenken waar dat echt een goede oplossing is. Wat ga je doen als je een message ontvangt met een lage prioriteit, en er komt een fractie later een message door met een hoge prioriteit?

[redesign]

EddoH schreef op woensdag 16 oktober 2013 @ 15:06:
Ik snap er werkelijk geen ene zak meer van

Messenger Message en Thread Message? Een Message is een Message in Android, geen idee waar dat verschil vandaan komt.

We kunnen je beter helpen als je je concrete probleem wat beter beschrijft in plaats van problemen met een theoretische implementatie

Het spookt in mijn hoofd van alle begrippen die ik mij nog eigen moet maken, sorry

Dus een Android Messenger message is hetzelfde als een Thread message? Huh? Nu snap ik het niet meer. Een Messenger message wordt toch "plat geslagen" om via IPC verstuurt te worden richting de andere kant, en vervolgens weer "opgeblazen" (recreated) aan de ontvangende kant. Tenminste dat leert mij de Parcelable interface.
Een Thread message is volgens mijn bescheiden begrip dus een ander soort message (die niet "plat geslagen" wordt) maar rechtstreeks van de ene Thread naar de andere Thread gestuurd kan worden, toch?

Zoals ik het nu zie moet ik nog veel lezen om alle kronkels uit mijn hoofd te krijgen....

[redesign]

Verwijderd schreef op woensdag 16 oktober 2013 @ 15:12:
[...]

Volgens de topicstart heeft hij geen invloed op de messages die binnen komen bij het process. De messages zouden dus altijd bij de main thread terecht komen.

---

Waarom denk je eigenlijk een message priority nodig te hebben? Ik kan eigenlijk geen situatie bedenken waar dat echt een goede oplossing is. Wat ga je doen als je een message ontvangt met een lage prioriteit, en er komt een fractie later een message door met een hoge prioriteit?

Goeie vraag! De Type_A berichten zijn stuur berichten terwijl Type_B/C/D data berichten zijn die minder belangrijk zijn dan Type_A berichten. Type_A berichten wil ik dus niet "achteraan de rij" parkeren die dan vervolgens veel te laat af worden geleverd aan de kant van de ontvanger.
Type_A berichten gaan dus (bijna) altijd voor Type_B/C/D tenzij ik net een Type_A verstuurd heb, dan is het zinloos om weer een Type_A voor te laten gaan op een ander type bericht.

Ik weet niet of een PriorityQueue een goede oplossing is, ik zoek naar een mechanisme dat dit kan bewerkstelligen, dan kom ik al gauw uit op een berichten queue. Geen idee of dat het beste is?

[EddoH]

java.lang.Object
↳ android.os.Message

Messenger:
send(Message message)

Handler:
A Handler allows you to send and process Message and Runnable objects associated with a thread's MessageQueue

Ik weet niet over welke 'Thread message' en 'Messenger message' je het hebt...

[redesign]

EddoH schreef op woensdag 16 oktober 2013 @ 15:55:
java.lang.Object
↳ android.os.Message

Messenger:
send(Message message)

Handler:
A Handler allows you to send and process Message and Runnable objects associated with a thread's MessageQueue

Ik weet niet over welke 'Thread message' en 'Messenger message' je het hebt...

Dat is 1 deel van het verhaal. Dit deel wat je noemt is het deel in mijn applicatie dat communiceert tussen Activity (client) en Service (server) door middel van IPC. Dan heb je een Messenger nodig (tenminste er van uitgaande asynchroon verkeer tussen client en server).

Deel 2 van het verhaal is dat binnen de Service er onderling tussen verschillende Threads gecommuniceerd moet worden (doorsturen berichten, nieuwe berichten versturen, reageren op andere berichten, etc). Dat is (volgens mij) een Producer-Consumer patroon, zie:
http://docs.oracle.com/ja...urrent/BlockingQueue.html

Nu vraag ik mij af of je een message dat vanuit een Android Messenger is verstuurd ook moet doorsturen naar een Thread binnen een andere Service?? Een ander (vaag) idee dat ik had was om in elke Thread een Messenger te gebruiken. Dus elke Thread krijgt zijn eigen Inbox/Outbox. Ik denk wel dat dit een beetje "teveel van het goede" is

Als je dit voorbeeld bekijkt zie je dat er onderling tussen de twee Threads een Drop object wordt uitgewisseld: http://docs.oracle.com/ja...oncurrency/guardmeth.html
Dit Drop object is dan dus de message.

Ah, wacht....Als ik jou nu goed begrijp kan ik dus "gewoon" de Android Message (http://developer.android....e/android/os/Message.html) objecten van de ene Thread naar de andere sturen?
Als dit zo is, dan moet ik wel nog een aparte Handler per Thread hebben die uitzoekt welk type bericht ie heeft ontvangen, en die Handler implementatie verschilt per Thread natuurlijk.

Zit ik in de juiste richting nu?

[EddoH]

redesign schreef op woensdag 16 oktober 2013 @ 16:09:
[...]


Dat is 1 deel van het verhaal. Dit deel wat je noemt is het deel in mijn applicatie dat communiceert tussen Activity (client) en Service (server) door middel van IPC. Dan heb je een Messenger nodig (tenminste er van uitgaande asynchroon verkeer tussen client en server).

...

Ah, wacht....Als ik jou nu goed begrijp kan ik dus "gewoon" de Android Message (http://developer.android....e/android/os/Message.html) objecten van de ene Thread naar de andere sturen?
Als dit zo is, dan moet ik wel nog een aparte Handler per Thread hebben die uitzoekt welk type bericht ie heeft ontvangen, en die Handler implementatie verschilt per Thread natuurlijk.

Zit ik in de juiste richting nu?

Ja, de messaging manier die je gebruikt voor Activity naar Service kun je inderdaad ook gebruiken voor inter-thread communicatie. Sterker, het is de aanbevolen manier.

Java:

class MyThread extends Thread {
    public Handler mHandler;

    @Override
    public void run(){
           Looper.prepare();

           mHandler = new Handler() {
                   public void handleMessage(Message msg) {
                      
                   }
           };
           Looper.loop();
    }

Zie bijvoorbeeld: http://techtej.blogspot.n...ng-data-between-main.html

[ Voor 18% gewijzigd door EddoH op 16-10-2013 16:29 ]

[redesign]

EddoH schreef op woensdag 16 oktober 2013 @ 16:24:
[...]
Ja, de messaging manier die je gebruikt voor Activity naar Service kun je inderdaad ook gebruiken voor inter-thread communicatie. Sterker, het is de aanbevolen manier.

Oh, NOU snap ik het (pas)!

Je kan werkelijkwaar alles in een Threads queue plempen, dus ook Drop objecten naast Message objecten. Ik dacht dat je een speciaal Thread message object nodig had. Tjonge, wat een moeilijk denken van mij

Als ik de HandlerThread class gebruik (http://developer.android....oid/os/HandlerThread.html) dan heb ik al een standaard implementatie, maar die maakt dan wel gebruik van een Looper (http://developer.android....ce/android/os/Looper.html) ipv een PriorityQueue.

Als ik nu een eigen (voor de desbetreffende Thread die de berichten verstuurd/ontvangt) interne PriorityQueue implementatie maak, of "gewoon" twee MessageQueue's gebruik dan kan ik deze Type_A / B/C/D berichten zo detecteren.
Of wacht eens.. ik kan ook gewoon twee (Array)Lists gebruiken wanneer de Thread de berichten ontvangt in de Handler en dat ik in de Handler (handleMessage) uitzoek welk bericht in welke list terecht moet komen. De handleMessage() is dan niets anders dan een postsorteerder.

Het echte "handle"-werk laat ik dan aan de Thread zelf over die af en toe eens kijkt of er nog nieuwe post is binnengekomen in ArrayList Type_A en/of ArrayList Type_B/C/D.

Ondertussen ook via Google het volgende gevonden:
http://techtej.blogspot.n...ng-data-between-main.html

Volgens mij is dat precies wat ik nodig heb?

Edit: dat is ook toevallig, allebei dezelfde link gevonden

[redesign]

Maakt het nog wat uit vanuit welke Thread ik e.e.a. verstuur naar een andere Thread.

Stel ik krijg een Message binnen van een Activity. Deze activity heeft zijn eigen replyTo Messenger in het Message object meegegeven. Vervolgens krijg ik dit bericht binnen op de main-thread van de Service. De main-Thread handler kijkt dan alleen naar de msg.what integer en kan zo bepalen in welk bereik het bericht zit, en dit bericht doorsturen naar de betreffende Thread. De betreffende Thread ontvangt de message, doet er iets mee, en vervolgens creert deze Thread een nieuw Message zonder een replyTo adres erin (omdat de interne structuur gewijzigd kan worden en ik geen client wil hebben die onderling met threads uit mijn service rechtstreeks gaat babbelen).
Wat moet er gebeuren vanuit de "worker" thread om het bericht te versturen, moet ik dit Message object dan weer eerst naar de main-thread sturen, die er vervolgens een replyTo adres in propt (volgens mij hoeft DAT helemaal niet, want de client heeft al de Messenger inbox van de Service ontvangen via de IBinder interface tijdens binding) en dan weer doorstuurt naar de client???

Ik weet dus niet of workerThread rechtstreeks Message objecten kunnen versturen naar de client. Ik heb iets gelezen over UI elementen die alleen op de main-thread/ui-thread geupdate mogen worden en niet vanuit een worker-thread. Is dit ook zo voor Message objecten?
Ik kan mij daar wel iets bij indenken, anders wordt het zoeen zooitje: iedereen babbelt dan maar door elkaar heen. Wellicht misschien een idee om een DispatcherThread te gebruiken die ook bijhoudt wie met wie communiceert en of er al een reactie is verstuurd? Zo kan men ook in de gaten houden of een client (Activity of andere Service) uberhaupt al antwoord heeft gehad.

Ik ben wel al een stukje opgeschoten vandaag. Niet qua implementatie, wel qua begripvorming

Edit: typos

[Verwijderd]

Als je high-prio en low-prio events hebt, maak dan gewoon meerdere worker threads aan, en geef worker threads welke aan low-prio messages werken een lagere prioriteit in het OS.

[pedorus]

Er is gewoon een PriorityBlockingQueue, dus waarom die niet gewoon gebruiken?

[redesign]

Verwijderd schreef op woensdag 16 oktober 2013 @ 17:36:
Als je high-prio en low-prio events hebt, maak dan gewoon meerdere worker threads aan, en geef worker threads welke aan low-prio messages werken een lagere prioriteit in het OS.

Het gaat er meer om dat ik per apparaat dat ik aanstuur vanuit de Android applicatie een aantal workerthreads heb "draaien" in de Service die de communicatie en de "interne administratie" in de service voor rekening nemen maar waarbij er maar 1 Thread is die daadwerkelijk "praat" met het andere apparaat.
Dus er komen meerdere berichten binnen in de groep van "worker" threads, maar er is maar 1 Thread die bepaalt welk bericht als eerste "de deur uit gaat". Dus in die ene Thread moet ik een soort van mechanisme hebben dat weet welk bericht als eerste te versturen. Afhankelijk van hoeveel apparaten er zijn aangesloten, ook weer meerdere "workerThread"-groepen en dus ook meerdere communicatieThreads, en dus ook (meer) willekeurige berichten door elkaar heen verstuurd worden waarvan ik niet vooraf kan weten welke als eerste binnenkomt. meer apparaten aangesloten = meer berichten = meer willekeur van volgorde van berichten.

Je oplossing zou mooi zijn als dat zou kunnen, maar helaas is het maar 1 Thread per apparaat die weet wat te doen met de berichten (althans, als ik het goed implementeer natuurlijk )

[redesign]

pedorus schreef op woensdag 16 oktober 2013 @ 17:45:
Er is gewoon een PriorityBlockingQueue, dus waarom die niet gewoon gebruiken?

Dit klinkt spannend, en wellicht het ik dit nodig. Alleen snap ik het niet
Ik heb de javadoc gelezen, maar dat roept bij mij vraagtekens op en verkapte vreugde tegelijkertijd. Dat laatste omdat ik denk dat dit mij wel eens zou kunnen helpen, al zie ik nog niet in hoe precies.

Als je wat meer tekst en uitleg zou willen geven, graag... want als ik het alleen uit de javadoc moet halen ben ik nog weken bezig voordat het kwartje is gevallen denk ik.

Ik ben een en al oor

[pedorus]

Je moet zorgen dat MsgType_B, MsgType_C en MsgType_D afstammen van 1 klasse MsgType, welke Comparable implementeert in de volgorde zoals je wil. (Alternatief kun je ook een hulpklasse gebruiken die Comparable implementeerd en er een op kan slaan). Dan kun je een PriorityBlockingQueue<MsgType> gebruiken. In aanbiedende threads doe je een Put() op de queue, in de verwerkende thread gebruik je Take() in een oneindig loopje. Eventueel een stop-element oid gebruiken om uit dit oneindige loopje te komen, zodat je netjes kan afsluiten.

[redesign]

pedorus schreef op woensdag 16 oktober 2013 @ 19:08:
Je moet zorgen dat MsgType_B, MsgType_C en MsgType_D afstammen van 1 klasse MsgType, welke Comparable implementeert in de volgorde zoals je wil. (Alternatief kun je ook een hulpklasse gebruiken die Comparable implementeerd en er een op kan slaan). Dan kun je een PriorityBlockingQueue<MsgType> gebruiken. In aanbiedende threads doe je een Put() op de queue, in de verwerkende thread gebruik je Take() in een oneindig loopje. Eventueel een stop-element oid gebruiken om uit dit oneindige loopje te komen, zodat je netjes kan afsluiten.

Dit klinkt voor mij als "te kort door de bocht". Ik denk even met je mee, wellicht dat het inderdaad gaat werken...

De berichten die worden verstuurd zijn van het type Message (http://developer.android....e/android/os/Message.html).
Deze Message objecten bevatten een msg.what integer ID dat het type bericht typeert. Verder zit in dit Message object nog een aantal data objecten die gebruikt gaan worden bij het versturen, op zich niet zo belangrijk, dat zijn de details.
Ik zou dus deze Message class kunnen afleiden naar MyMessage en een Comparator / Comparable in deze class implementeren. Ik neem aan dan ook meteen hashCode() en equals() implementeren?
Dan gebruik ik vervolgens een PriorityBlockingQueue<MyMessage> queue, in de Thread(s) die deze Message objecten ontvangen. De PriorityBlockingQueue sorteert dan zelf - wanneer een nieuw Message binnenkomt - de berichten opnieuw naar deze msg.what ID. Dat zou op zich kunnen werken, maar dan zit ik met 1 ding: wat als ik zojuist een Type_A bericht heb verstuurd en de volgende Message is een Type_B, maar voordat ik een nieuwe queue.take() opdracht uitvoer, komt er weer een Message van het Type_A in de queue terecht. Deze zou dan weer vóór Message Type_B komen bij de eerstvolgende queue.take(). Dat is niet de bedoeling. Dat is BIJNA wat ik wil.
Het nadeel is ook dat ik hier over een theoretische implementatie praat, wat als nadeel heeft dat ik niet kan uittesten of het ook veel uitmaakt als Type_A twee keer achter elkaar gestuurd wordt.
Aan de ontvangende hardware kant kan ik niets veranderen, dus dat zou met experimenteren laten bewezen moeten worden of dat wel of niet gaat werken. Toch denk ik dat ik met twee queues moet werken, zodat ik ook kan kijken hoeveel Type_B/C/D berichten ik al heb verstuurd alvorens ik weer een Type_A bericht de deur uit stuur.

Voor het oneindige loopje zou ik een Looper (http://developer.android....ce/android/os/Looper.html) kunnen gebruiken, toch? Of zijn daar ook nog andere smaken in?

Ik kan natuurlijk ook een PriorityBlockingQueue gebruiken voor Type_B/C/D en een MessageQueue voor Type_A. En dan de Thread zelf laten uitzoeken welke wanneer uit te lezen.

Schiet me nog iets te binnen: zodra ik een bericht heb verstuurd, moet ik dan de Thread in de wacht zetten? Het versturen doe ik in een synchronized method omdat dit natuurlijk niet halverwege mag gepauzeerd worden. In de wacht zetten bedoel ik: tijd vrijmaken om andere Threads ook aan het woord te laten. Er kunnen namelijk meerdere apparaten tegelijkertijd bediend worden die wellicht OOK een Type_A bericht in hun queue hebben staan. Dus hoe geef ik eigenlijk aan dat de thread wel moet blijven werken, maar dat de thread niet alle tijd moet "opslurpen" om eerst alle berichten uit de queue te gaan versturen alvorens een andere Thread daarna pas "de spreekbeurt" te geven.

Type_A berichten zijn nogal tijdsgevoelig, vandaar dat er zo weinig mogelijk vertraging mag ontstaan bij verschillende apparaten. Er mag wel wat tijd zitten tussen twee Type_A berichten bij hetzelfde apparaat, maar niet bij meerdere apparaten tegelijk. Wat ik bedoel is eigenlijk: alle apparaten ontvangen (wanneer van toepassing uiteraard) gelijktijdig een Type_A bericht als dat bericht naar alle apparaten wordt verstuurd.

Grr,.. wie bedenkt nou ook zo'n hardware...

Volgens mij ben ik er BIJNA. Okay, theoretisch dan

[pedorus]

redesign schreef op woensdag 16 oktober 2013 @ 20:05:
Het versturen doe ik in een synchronized method omdat dit natuurlijk niet halverwege mag gepauzeerd worden.

Synchronized zorgt er alleen maar voor dat je niet in een synchronized zone van 1 object kan zitten met 2 threads tegelijkertijd. Niet-systeemthreads kunnen altijd onderbroken worden.

Qua prioriteit zou je bijvoorbeeld kunnen zeggen dat berichten op milliseconden van aankomst worden gescheduled, maar type a berichten x milliseconden voordeel krijgen (en type b berichten y ms, enz). Als type a berichten gedropt kunnen worden als er al een nieuw type a bericht in de queue staat, dan zou je met peek() kunnen werken.

Met een oneindig loopje bedoel ik gewoon while(true) { m = queue.take(); handle(m); }

[redesign]

pedorus schreef op woensdag 16 oktober 2013 @ 21:46:
[...]

...
Niet-systeemthreads kunnen altijd onderbroken worden.
...
Als type a berichten gedropt kunnen worden als er al een nieuw type a bericht in de queue staat, dan zou je met peek() kunnen werken.

[/quote]
Aha, dat van die niet-systeemthreads wist ik niet.

Jammer dat er geen peek() method bestaat voor "de daarna eerste" om zo te kunnen kijken of het tweede bericht (gezien vanaf de kop) ook een Type_A bericht is. Maw: als peek() bericht Type_A oplevert, kijk dan of er nog andere in de queue staan van een ander type. Wellicht kan ik ook met take() een Type_A bericht in een andere queue zetten wanneer ik zojuist een Type_A bericht heb verstuurd.
Het is nu nog een beetje koffie dik kijken, want ik kan het nog niet uittesten op de hardware zonder implementatie

Ik denk dat ik eerst maar eens recht-toe-recht-aan programmeer: alles gewoon wat binnenkomt doorsturen in de volgorde van ontvangst. Dan zie ik later wel wanneer de hardware kuren begint te vertonen. Een queue of comparator extra kan altijd nog, het is gelukkig niet gemaakt van steen
Ik weet zeker dat - wanneer ik meerdere apparaten tegelijkertijd ga besturen - er problemen gaan ontstaan. Eerst maar eens 1 apparaat aanslingeren met mijn applicatie, dan ben ik al ver gekomen!

Iedereen hartelijk dank voor jullie hulp en bijdrage.

[EddoH]

Ik ben wel benieuwd wat voor soort apparaat je eigenlijk moet aansturen, want de reden van die prioriteiten en potentiële problemen bij 2 keer hetzelfde bericht snap ik niet echt.

[ Voor 25% gewijzigd door EddoH op 17-10-2013 10:42 ]

[redesign]

EddoH schreef op donderdag 17 oktober 2013 @ 10:42:
Ik ben wel benieuwd wat voor soort apparaat je eigenlijk moet aansturen, want de reden van die prioriteiten en potentiële problemen bij 2 keer hetzelfde bericht snap ik niet echt.

Dat mag ik helaas niet zeggen (ivm geheimhoudingsplicht)