Bocsi, kicsit "sok ho esett" melo fronton, nem jutott ido forumozni.
Egy nagyjabol valid problema, ami -szerintem- az altalam felvetett problemara vezetheto vissza.
A szereplok:
- Message (v. Job) osztaly, ami AutoCloseable, mert valamilyen egyeb resource-ot is aggregal.
- n db MessageHandler osztaly, aminek van egy void process(Job) szignaturaju metodusa. Fontos: a process metodus aszinkron muvelet, tehat visszater mielott befejezodne, tovabba a MessageHandlerek parhuzamosan dolgoznak.
Tehat az uzenet feldolgozasa a kovetkezokeppen nezne ki idealis esetben:
for(;;) {
Message msg = nextMessage();
for(MessageHandler handler : messageHandlers) {
handler.process(msg);
}
}
Itt a using-with-resource idioma nem mukodik, leven a process() aszinkron. Szoval szerintem itt nincs automatikus strategia az msg bezarasara (Java/C# esetben). Termeszetesen van megoldas: adni kell egy callback-et extra argumentumkent a process() fuggvenynek igy tudnak jelezni a handler-ek, amikor vegeztek. Viszont csodak-csodaja: ezzel eppen referenciaszamlalast valositasz meg (tulajdonkeppen minden egyes process hivas egy +1 a referencianak es a callback hivas egy -1).
C++-ban RAII + rc-vel (shared_ptr a Message objektumra) nagyon szepen impliciten kezeli.
Jelen esetben a Message objektum a resource, amihez a MessageHandler-ek parhuzamosan fernek hozza. A problemat vegso soron az jelenti, hogy nehez meghatarozi, hogy melyik az a determinisztikus pillanat, amikor a close() biztonsagosan meghivhato az uzenetre (amikor az utolso MessageHandler is vegzett).
Termeszetesen a pool egy hasznos megoldas ebben a problemaban (en is hasznalnam). Ugyanis szeretnenk magunknak egy flow-control elemet a rendszerben. Ha a handlerek lassuak es az uzeneteket tul gyorsan olvassuk, akkor elszall a memoriahasznalat. Ezert csinalunk mondjuk egy 1000 elemu pool-t az uzeneteknek. Ha van meg a pool-ban szabad elem, akkor olvasunk a halozatrol es letrehozzuk a Message objektumot es kezdjuk a feldolgozast. Egyebkent varunk, hogy a pool-ban ujra legyen hasznalhato eroforras. Tehat ez hasznos komponense a megoldasnak, de a teljes problemat nem oldja meg: jelesul mikor adhatjuk vissza az eroforrast legkorabban.
Hat roviden ennyi. Remelem nagyjabol erthetoen irtam le a dolgokat.