[alg/java] naamgevings vraag voor threadpool achtig probleem

[Alarmnummer]

Ik ben veel met channels bezig en daarvoor ben ik bepaald object nodig en ik kom eigelijk niet uit een goeie naam voor dit object terwijl ik er al meer dan een week over loop na te denken.

Laat ik eerst de parallel trekken:
In java heb je sinds versie 5 beschikking over de Executor. De Executor is verantwoordelijk voor het executen van een taak (een Runnable). Een van de implementaties hiervan is de ThreadPoolExecutor. Je kunt aan de ThreadPoolExecutor een taak geven, en de threadpoolexecutor die slaat het op in zijn Queue. De threads in deze threadpoolexecutor liggen te slapen op deze queue, en een van de threads zal de taak uit de queue halen, uitvoeren en wachten op de volgende taak. Nadat de taak is uitgevoerd kan hij in principe gedisposed worden.

Wat ben ik nodig:
Ik wil ook een bak met threads maar deze threads moeten de hele tijd 1 taak blijven uitvoeren (ze zijn dus nooit klaar) Misschien zul je denken... wat heb je hieraan? Ik ben die threads nodig zodat ze kunnen 'zuigen' aan channels en berichten eruit kunnen halen om te gaan verwerken. Aangezien ik erg veel doe met concurrency en threading wil ik deze functionaliteit niet alleen voor channels gaan bouwen, maar het onderdeel uit laten maken van mijn concurrency library.

Samenvatting:
Ik ben op zoek naar de naam van een 'pool' met threads. Deze pool kan groeien en krimpen (en stoppen/starten) en al deze threads die blijven 1 taak herhalend uitvoeren.

Het schrijven van dit object is geen probleem.. maar een duidelijke naam ervoor bedenken wel.

ps:
zuigpool/suckpool is geen optie

[ Voor 11% gewijzigd door Alarmnummer op 21-08-2005 19:31 ]

[H!GHGuY]

RepeatPoolExecutor

[Alarmnummer]

HIGHGuY schreef op zondag 21 augustus 2005 @ 20:26:
Repeat

Het is idd iets dat zich herhaal.

Pool

Een pool is iets waarin je mbv caching een bepaalde winst kan halen. Je kunt objecten poolen, connections poolen, threads poolen. Maar het het idee is dat uiteindelijk het object weer terug gegeven gaat worden aan de pool, zodat het door anderen weer gebruikt kan worden. In dit geval is daar dus geen sprake van aangezien er dus nooit iets terug gegeven gaat worden. Daarom denk ik dat pool niet zo`n verstandige naam is.

Executor

Hmm... ik had daar zelf ook al aan gedacht maar 2 dingen:
1) je wilt een duidelijk afscheiding tussen de bestaande Executor, zodat het duidelijk is dat het iets heel anders is.
2) eigelijk kan een ander er geen taken op executen. Hij voert een interne taak herhalend (en door merdere threads) tegelijk uit dus nadat het gebouwd is, is het voor de rest van de wereld al geen executor mee... (vaag argument trouwens).

Leuk dat je een poging waagt.

ps:
Ik geloof dat er wel soortgelijke onderdelen in bv een operating system zitten. Misschien dat ik daar de naam vandaan kan halen

[alg]
Repeater... misschien dat dat iets zou kunnen zijn...

[ Voor 3% gewijzigd door Alarmnummer op 21-08-2005 20:41 ]

[lordsnow]

Zoiets als "ThreadsLooper"?

p.s. In je verhaaltje gebruik je meerdere keren "ben" waar het "heb" hoort te zijn.

[whoami]

RecurrentThreadContainer oid.

Recurrent -> terugkerend
Thread -> tja
Container -> jouw bak die kan groeien en krimpen.

Alhoewel Container misschien nog niet zo goed is.

[Alex]

whoami, anders maak je van Container Collector. Een verzamelaar van threads.
Edit:
Twijfel ernstig of Collector op zijn plek is... * Alex kijkt naar dit linkje

Waarom trouwens niet 911ThreadManager?

[ Voor 44% gewijzigd door Alex op 21-08-2005 21:25 ]

[Alarmnummer]

lordsnow schreef op zondag 21 augustus 2005 @ 20:55:
Zoiets als "ThreadsLooper"?

Soms moet je niet altijd zeggen hoe het gedaan wordt, maar wat er gedaan wordt. En Looper.. tja... daar zit ook wel iets in.

p.s. In je verhaaltje gebruik je meerdere keren "ben" waar het "heb" hoort te zijn.

Laten we dat op Gronings dialect gooien

[Alarmnummer]

whoami schreef op zondag 21 augustus 2005 @ 21:10:
RecurrentThreadContainer oid.

Hmmm.. het is soms handiger om het wat van het hoe te scheiden. Een naam dat beschrijft wat het doet is handiger dan een naam die beschrijft hoe hij dat doet. Vooral als je van implementatie wilt kunnen wisselen is het handig om zo`n naam te bedenken voor je interface.

Kijk bv naar Executor.. Executor is een ding dat taken uitvoert, maar over de realisatie ervan zie je niets terug in de naam. Totdat je bij de ThreadPoolExecutor uitkomt.. want dat is een concrete implementatie. Ik heb voor test doeleinden ook een DirectExecutor die de taak uitvoert op de thread die de taak wil uitvoeren

Recurrent -> terugkerend
Thread -> tja
Container -> jouw bak die kan groeien en krimpen.

Alhoewel Container misschien nog niet zo goed is.

Goeie namen bedenken is complex. Tot zover staat Repeater bij mij boven aan.

[ Voor 8% gewijzigd door Alarmnummer op 21-08-2005 21:32 ]

[Alarmnummer]

Alex de Groot schreef op zondag 21 augustus 2005 @ 21:23:
whoami, anders maak je van Container Collector. Een verzamelaar van threads.

Hmm.. de Threads worden niet door het object verzameld. Het is niet dat je zo maar andere threads er bij kan zetten.. dus collector zou je op een verkeerde been kunnen zetten.

Twijfel ernstig of Collector op zijn plek is... * Alex kijkt naar dit linkje

Ik zal die link eens bekijken.

[momania]

Listener misschien een goede naam?
Ze blijven continu zuigen, dus luisteren naar iets. Deze kan je dan bij elkaar mooi in een ListenerPool gooien

[H!GHGuY]

de naam Repeater zou ik geven aan 1 thread die telkens hetzelfde doet...

maak er dan RepeaterPool oid van...

[Alarmnummer]

HIGHGuY schreef op zondag 21 augustus 2005 @ 23:20:
de naam Repeater zou ik geven aan 1 thread die telkens hetzelfde doet...

Dat hoeft niet. Als je kijkt naar de Executor dan kunnen daar ook gerust een pool van threads achter zitten. Vandaar dat ik dus geen problemen heb met Repeater.. hij kan repeaten.. hoe hij dat doet intern.. dat is een 2e.

maak er dan RepeaterPool oid van...

Met pool ben ik sowieso niet zo blij. Boven in het topic staat mijn argumentatie tegen deze naam. Tot zover ben ik erg tevreden met Repeater en heb net even een implementatie in elkaar gezet.

Dit is de code, maar het is nog niet klaar en moet nog getest worden.

Java:

public class StdRepeaterService implements RepeaterService {

    private final static int NOT_STARTED = 0;
    private final static int RUNNING = 1;
    private final static int TERMINATING = 2;
    private final static int TERMINATED = 3;

    private int _threadCount;
    //factory for new threads
    private final ThreadFactory _threadFactory;
    //the task to execute repeatable.
    private final Runnable _task;
    //Set containing all worker threads 
    private final HashSet<Worker> _workers = new HashSet<Worker>();
    //Lifecycle state
    private volatile int _runstate = NOT_STARTED;

    public StdRepeaterService(Runnable task) {
        this(task, 1);
    }

    public StdRepeaterService(Runnable task, int threadCount) {
        this(task, threadCount, new StdThreadFactory("repeaters"));
    }

    public StdRepeaterService(Runnable task, int threadCount, ThreadFactory threadFactory) {
        if (task == null || threadFactory == null) throw new NullPointerException();
        if (threadCount < 0) throw new IllegalArgumentException();
        _task = task;
        _threadCount = threadCount;
        _threadFactory = threadFactory;
    }

    public int getThreadCount() {
        return _threadCount;
    }

    public ThreadFactory getThreadFactory() {
        return _threadFactory;
    }

    public Runnable getTask() {
        return _task;
    }

    public synchronized boolean isRunning() {
        return _runstate == RUNNING;
    }

    public synchronized boolean isNotStarted() {
        return _runstate == NOT_STARTED;
    }

    public synchronized boolean isTerminating() {
        return _runstate == TERMINATING;
    }

    public synchronized boolean isTerminated() {
        return _runstate == TERMINATED;
    }

    public void setThreadCount(int threadCount) {
        if (threadCount == 0) throw new IllegalArgumentException();
        //todo
    }

    public synchronized void start() {
        if (_runstate != NOT_STARTED) throw new IllegalStateException();

        _runstate = RUNNING;

        for (int k = 0; k < _threadCount; k++) {
            Worker worker = new Worker();
            Thread thread = _threadFactory.newThread(worker);
            worker._thread = thread;
            _workers.add(worker);
            thread.start();
        }
    }

    public synchronized void shutdown() {
        if (_runstate != RUNNING) throw new IllegalStateException();

        _runstate = TERMINATING;

        //shutdown all the workers.
        for (Worker worker : _workers)
            worker._stop = true;

    }

    private class Worker implements Runnable {

        private volatile boolean _stop = false;
        //The thread that runs this Worker (todo: gebeurt nog niets mee)
        private Thread _thread;

        public void run() {
            while (!_stop) 
                _task.run();

            synchronized (StdRepeaterService.this) {
                _workers.remove(this);

                //if this StdRepeaterService is shutting down, and there are no more workers
                //then this StdRepeaterService is terminated.
                if (_runstate == TERMINATING && _workers.isEmpty())
                    _runstate = TERMINATED;
            }
        }
    }
}

[ Voor 74% gewijzigd door Alarmnummer op 21-08-2005 23:33 ]

[Alarmnummer]

momania schreef op zondag 21 augustus 2005 @ 22:52:
Listener misschien een goede naam?
Ze blijven continu zuigen, dus luisteren naar iets.

Het is geen garantie dat ze een naar iets 'luisteren'. Ik wil deze Repeater inzetten in een omgeving waar ik veel werk met slapende threads (de channels die zijn blocking).

Deze kan je dan bij elkaar mooi in een ListenerPool gooien

Ik vind de naam Listener sowieso al een beetje misleidend. En Pool kan het ook niet worden

[momania]

Alarmnummer schreef op zondag 21 augustus 2005 @ 23:39:
[...]

Het is geen garantie dat ze een naar iets 'luisteren'. Ik wil deze Repeater inzetten in een omgeving waar ik veel werk met slapende threads (de channels die zijn blocking).

Ah, ok.... maar je gaf in je TS aan dat deze thread altijd blijven werken. Ik ging er dus even vanuit dat je geen slapende thread had, alleen een pool (ik gebruik het toch weer even ) die groter of kleiner kan worden

[Alarmnummer]

momania schreef op zondag 21 augustus 2005 @ 23:44:
[...]

Ah, ok.... maar je gaf in je TS aan dat deze thread altijd blijven werken.

Misschien heb ik me een beetje ongelukkig uitgedrukt. Maar het is de bedoeling dat ze 1 taak blijven herhalen en daarbij zal het vaak voorkomen dat ze tijdens het uitvoeren van die taak liggen te slapen.

Java:

class ChannelSucker implements Runnable{
     public void run(){
           Msg msg = _channel.take();
           ..doe iets met msg (kan een kostbare operatie zijn)
     }
}

Deze ChannelSucker kan door meerdere threads tijden lang achter elkaar afgedraaid worden.

Ik kan dan als volgt een repeater in elkaar zetten:

ChannelSucket sucker = new ChannelSucket();
Repeater repeater = new Repeater(sucker ,1);
repeater.start();

Nu worden automatisch alle berichten uit een bepaalde channel gezogen.. en kan ik ze bewerken.

Ik gebruik het op dit moment in een crawler proof of concept proefje om de Analyzer met de Crawler te koppelen via channels.

voorbeeldje met de repeaters erin:

Java:

public static void main(String[] args){
        Channel<FetchRequest> requestChannel = new StdBufferedChannel<FetchRequest>(500);
        Channel<FetchResult> resultChannel = new StdBufferedChannel<FetchResult>(50);

        RepeaterService fetchRepeater = new StdRepeaterService(5);
        Fetcher fetcher = new Fetcher(requestChannel,resultChannel,fetchRepeater);
        fetcher.start();

        RepeaterService analyzeRepeater = new StdRepeaterService(5);
        Analyzer analyzer = new Analyzer(resultChannel,requestChannel,analyzeRepeater);
        analyzer.start();

        try {
            requestChannel.put(new FetchRequest(new URL("http://dmoz.org/")));
        } catch (InterruptedException e) {
            e.printStackTrace();
        } catch (MalformedURLException e) {
            e.printStackTrace();
        }
}

[ Voor 49% gewijzigd door Alarmnummer op 21-08-2005 23:56 ]

[RedRose]

Repeater is hierin op zich imho wel werkend, alleen zou ik dan nog missen _wat_ het is dat wordt gerepeat..

Je had het over Tasks (om het generiek te houden).. TaskRepeater? <dingdatjecontinueviathreadsuitwillatenvoeren>Repeater?

/edit : en anders misschien toch iets doen met concurrency / recurrency.. 'ReconcurrencyService' .

[ Voor 30% gewijzigd door RedRose op 21-08-2005 23:56 . Reden: pfff ]

[H!GHGuY]

hmm, als je dan toch van die benaming Pool afwil, wat ik wel kan verstaan, waarom hou je't dan niet simpel bij "group" of iets dergelijks.

RepeaterGroup
RecurrentThreadGroup

whatever

[Plecky]

Als alternatief voor je Sucker (wat ik overigens een geniale term vind) zou je het in Java meer voorkomende Consumer kunnen overwegen, met als alliterair hoogtepunt de ConstantConsumerCollection

[RedRose]

Plecky schreef op zondag 21 augustus 2005 @ 23:56:
Als alternatief voor je Sucker (wat ik overigens een geniale term vind) zou je het in Java meer voorkomende Consumer kunnen overwegen, met als alliterair hoogtepunt de ConstantConsumerCollection

Ik heb niet de indruk dat in bovenstaande code van Alarmnummer iets wordt geconsumeerd.. het is eerder een manager / doorgeefluik (?).

[ Voor 3% gewijzigd door RedRose op 21-08-2005 23:59 ]

[Alarmnummer]

HIGHGuY schreef op zondag 21 augustus 2005 @ 23:56:
hmm, als je dan toch van die benaming Pool afwil, wat ik wel kan verstaan, waarom hou je't dan niet simpel bij "group" of iets dergelijks.

RepeaterGroup
RecurrentThreadGroup

whatever

Heel simpel. Probeer een onderscheid te maken tussen wat het object doet en hoe het object is opgebouwd. Voor interfaces is dit sowieso al essentieel. Alleen bij concrete eindclasses ga je meer de inhoud beschrijven.

Executor (hier zie ik niets over wel of geen threadpools)
ThreadPoolExecutor (nu is het duidelijk dat er een threadpool wordt gebruikt).

Hetzelfde geld voor de Repeater. Het doel ervan is een taak herhaaldelijk achter elkaar uit te voeren. Om mij part doe ik dat via RMI op een hele andere computer.. niemand hoeft te weten dat ik er een (dat zou ook nog kunnen) of meer threads voor gebruikt.

[Plecky]

RedRose schreef op zondag 21 augustus 2005 @ 23:59:
[...]
Ik heb niet de indruk dat in bovenstaande code van Alarmnummer iets wordt geconsumeerd.. het is eerder een manager / doorgeefluik (?).

Ja goed punt eigenlijk wel.
Er wordt inderdaad niet echt geheel geconsumeerd zover ik zie. (volgende keer even over de luiheid heen komen om een stuk code te lezen)
Andere analogie misschien dan? Funnel (trechter)?

[Alarmnummer]

RedRose schreef op zondag 21 augustus 2005 @ 23:59:
[...]
Ik heb niet de indruk dat in bovenstaande code van Alarmnummer iets wordt geconsumeerd.

De get op die channel is blocking. Op het moment dat er een bericht in die channel komt, dan kan de thread die op die channel ligt te slapen.. wakker worden en het bericht eruit halen. Ik wil verder een groep met threads die ligt te slapen op die channel, omdat het verwerken van de berichten een dure aangelegenheid kan zijn en waar eventueel veel io (en dan kan multithreading erg hanfig zijn) voor nodig is.

Je kunt mijn channels project hier bekijken.
http://members.home.nl/peter-veentjer01/index.htm

[H!GHGuY]

Alarmnummer schreef op zondag 21 augustus 2005 @ 23:59:
[...]

Heel simpel. Probeer een onderscheid te maken tussen wat het object doet en hoe het object is opgebouwd. Voor interfaces is dit sowieso al essentieel. Alleen bij concrete eindclasses ga je meer de inhoud beschrijven.

Executor (hier zie ik niets over wel of geen threadpools)
ThreadPoolExecutor (nu is het duidelijk dat er een threadpool wordt gebruikt).

Hetzelfde geld voor de Repeater. Het doel ervan is een taak herhaaldelijk achter elkaar uit te voeren. Om mij part doe ik dat via RMI op een hele andere computer.. niemand hoeft te weten dat ik er een (dat zou ook nog kunnen) of meer threads voor gebruikt.

ok: Repeater is je interface, en kies een van de andere voor je implementatie

het probleem met informatici (including me) is dat ze het altijd te ver zoeken
oplossing: drink je lazarus, en ga dan voor je probleem zitten

[Alarmnummer]

HIGHGuY schreef op maandag 22 augustus 2005 @ 00:11:
[...]
ok: Repeater is je interface, en kies een van de andere voor je implementatie

Idd.. maar ik ben nog niet helemaal uit de class hierarchie. Gewoonlijk boeit me dat niet zo, maar dit zijn classes/interfaces die ik in de toekomst in veel projecten ga gebruiken. Daarom wil ik iets dat uitbreidbaar is en daarom let ik daar extra op. Daarom werk ik ook vaak via een:

-codeclient-interface (minimale interface voor het hoofddoel)
-codeservice-interface (extends de code client interface.) deze bevat ook allerlei opstart,afsluit meuk.
-implementaties.

en ook via:
-basis interface
-specifkekere interface
-nog specifieker
-...
-end implementaties.

Geeft maximale vrijheid. En handig werken met abstracte classes geeft ook uitstekend hergebruik.

Dit zie je trouwens ook veel terug in betere libraries zoals het collection framework of in de concurrency library.

[ Voor 8% gewijzigd door Alarmnummer op 22-08-2005 00:18 ]

[Verwijderd]

RepetitiveThreadListExecutor
RepeadableThreadListExecutor
RepetitiveThreadQueueExecutor
RepeadableThreadQueueExecutor
?

[Alarmnummer]

Verwijderd schreef op maandag 22 augustus 2005 @ 16:40:
RepetitiveThreadListExecutor
RepeadableThreadListExecutor
RepetitiveThreadQueueExecutor
RepeadableThreadQueueExecutor
?

Repetitive ok..

Thread.. geef je weer de inhoud bloot.

List/Queue... geeft weer de inhoud bloot.. wie zegt dat ik een list of queue heb? Misschien heb ik ook maar 1 thread..misschien wel meer.. misschienheb ik er niet eens een.

Executor.. tja.. 1) naamsverwarring aangezien er al een executor is. 2) anderen kunnen niets op hem executen.. alhoewel... *zit eraan te denken om toch een startRepeatingTask toe te voegen*

Ik probeer bij interface te beschrijven wat het doet, en niet hoe het in elkaar zit.

Ik ben tot zover erg blij met de naam Repeater..

[ Voor 8% gewijzigd door Alarmnummer op 22-08-2005 17:21 ]

[Verwijderd]

Ik ging voor de uiteindelijke implementatie naam, en wel hierom:

Opzich vind ik Repeater persoonlijk wat vaag. Het zou een domain object kunnen zijn die een 'repeater' in een netwerk representeert. Vandaar dat ik voor een wat uitgebreidere naam ga.

Deze door jou genoemde 'repeater' is toch immers een object wat herhaaldelijk threads uitvoert? Dus een RepeatableThread (of ThreadRepeater) is dan al een vrij logische naam. Alleen impliceert dit een repeater voor 1 enkel thread object. En dat moet jouw object niet doen. Je hebt een collectie (ik vind persoonlijk queue mooier aangezien threads in een wachtrij staan). Tevens geeft dit aan dat je threads aan je 'repeater' kunt toevoegen en verwijderen. Deze klasse beslist ook over de executie van een thread dus executor heeft ook waarde in de naam.

Uiteraard is bijvoorbeeld ThreadQueue als apparte klasse te definieren. Vervolgens een ThreadQueueExecutor klasse om een thread 'normaal' af te handelen. En bijvoorbeeld een RepeatableThreadQueueExecutor als definitieve klasse.

[Alarmnummer]

Verwijderd schreef op maandag 22 augustus 2005 @ 17:38:
Ik ging voor de uiteindelijke implementatie naam, en wel hierom:

Opzich vind ik Repeater persoonlijk wat vaag. Het zou een domain object kunnen zijn die een 'repeater' in een netwerk representeert.

Hmm tja... bij Executor gebeurt dit ook.. dat zou ook iemand kunnen zijn die mensen loopt te executen Ik heb er dus geen probleem mee, dat ik een naam gebruikt die ooit misschien eens als domein object terug komt. Dat gebeurt me nu ook wel eens en heb ik ook geen problemen mee.

Vandaar dat ik voor een wat uitgebreidere naam ga.

Als je met uitgebreider duidelijker bedoelt dan heb ik er geen problemen mee. Het kan niet duidelijk genoeg zijn.

Deze door jou genoemde 'repeater' is toch immers een object wat herhaaldelijk threads uitvoert? Dus een RepeatableThread (of ThreadRepeater) is dan al een vrij logische naam.

Een van de implementaties van de Repeater zou dat met threads kunnen doen. Maar voor hetzelfde geld gebeurt het repeaten op de thread die het geheel start. Dus vandaar dat ik dit aspect uit de basis naam wil halen.

Alleen impliceert dit een repeater voor 1 enkel thread object. En dat moet jouw object niet doen. Je hebt een collectie (ik vind persoonlijk queue mooier aangezien threads in een wachtrij staan).

Geeft weer te veel informatie over de inhoud van het object vrij. En ze staan misschien wel in een wachtrij.. maar misschien ook niet.

Tevens geeft dit aan dat je threads aan je 'repeater' kunt toevoegen en verwijderen. Deze klasse beslist ook over de executie van een thread dus executor heeft ook waarde in de naam.

Yep.. maar nu zit je wel bij een concretere implementatie. En daar vind ik het niet zo`n probleem als je de inhoud in de naam beschrijft. Kijk naar de ThreadPoolExecutor, of de LinkedBlockingQueue... geven allemaal hun inhoud prijs.

Maar Executor en BlockingQueue zijn algemene begrippen die niet gekoppeld zijn aan een bepaalde implementatie. Dit geld ook voor de Repeater.

Uiteraard is bijvoorbeeld ThreadQueue

ThreadQueue vind ik een erg misleidende naam omdat het beschrijft hoe het object is opgebouwd maar absoluut niets vrijgeeft over het doel van het object. Het doel is om taken te repeaten en niet om Threads te queuen.

als apparte klasse te definieren.

interface he

Vervolgens een ThreadQueueExecutor klasse om een thread 'normaal' af te handelen.

Volgens mij kom je nu aan bij een Executor en zijn ThreadPoolExecutor. Ik wil sowieso geen Executor in de naam omdat je verwarring kan krijgen met de Executors uit java 5. Threading is al complex genoeg, zorg dan niet voor naamsverwarring.

En bijvoorbeeld een RepeatableThreadQueueExecutor als definitieve klasse.

Ik ben geen voorstander va ThreadQueueExecutor, dus automatisch ook niet van deze naam.

[ Voor 11% gewijzigd door Alarmnummer op 22-08-2005 18:09 ]

[Verwijderd]

Ik ook poging doen

SingleTaskThreadRepeater / Manager,
DedicatedThreadRepeater,

Ipv dedicated zou je misschien ook nog isolated kunnen gebruiken om te benadrukken dat ze 1 ding blijven uitvoeren.

[Salandur]

Mss is RepeatManager iod. Het 'managed' toch duidelijk iets dat 'herhaalt' moet worden.

Of gezien het feit dat er een bepaalde task herhaald wordt 'TaskManager', maar dat is te algemeen en te verwarrend. 'UniqueTaskManager' zou dan beter zijn. Je kan ook de basisinterface ook 'OngoingTask' noemen of 'ContinueTaak', maar jou naamgeving in acht nemend zal de engelse versie je wel beter aanspreken.

[ Voor 68% gewijzigd door Salandur op 22-08-2005 20:29 ]

[Verwijderd]

@Alarmnummer

Wat je dus feitelijk zegt is dat je niet een naam wilt hergebruiken aangezien deze al in de java standard lib voorkomt maar zoekt naar een synoniem. Ik vind dat persoonlijk onnodig onduidelijkheid scheppen over je naamgeving. Dan krijgen we straks Objects en Items/ Rows en Records/ String en Text, etc. Ik vermijdt deze liever.

Waarom wil je persee nog een keer de basis vast leggen? Wat voor taken zou een Repeater vervullen en bestaat daar dan niet al een klasse voor met een soortgelijke functionaliteit? Ik denk dus dat je het onnodig moeilijk voor jezelf aan het maken bent.

[Alarmnummer]

Verwijderd schreef op dinsdag 23 augustus 2005 @ 00:01:
@Alarmnummer

Wat je dus feitelijk zegt is dat je niet een naam wilt hergebruiken aangezien deze al in de java standard lib voorkomt maar zoekt naar een synoniem.

Hmmm nee. Als Executor echt een goeie naam geweest was, dan zou het misschien een optie zijn geweest (maar wel met een stevig tegenargument omdat er al een Executor in de concurrency control library van java 5 zit, en concurrency control over het algemeen al wordt beschouwd als erg complex wil ik geen naamsverwarring). Maar ik vind het geen goeie naam, omdat je er niets op kan executen. Ik wil een naam waarbij ik meteen iets heb van.. oja.. dat is zo`n ding. Ik wil er niet te lang over nadenken. Alles wat ik niet in 5 seconden kan begrijpen is fout.. Repeater.. duidelijk.. executor.. niet duidelijk.

Waarom wil je persee nog een keer de basis vast leggen? Wat voor taken zou een Repeater vervullen en bestaat daar dan niet al een klasse voor met een soortgelijke functionaliteit?

Welke basis wil ik vastleggen die er al is? Ik ben meer dan thuis in de concurrency control framework van Java 5 en de door mij gewenste functionaliteit is niet aanwezig. Ik kan het gedrag deels simuleren mbv een ThreadPoolExecutor en de afterExecute methode overriden om daar een nieuwe runnable te gaan queuen. Maar je krijgt dan sowieso gedonder bij het groeie/krimpen van de pool size.. en je krijgt gedonder om de 1e runnable`s er in te zetten.

Persoonlijk vind ik dit een hele foute manier van werken en daarom wil ik objecten waarik ik meteen kan begrijpen wat het doel ervan is. Ik wil andere techneuten kunnen uitleggen hoe systemen in grote lijnen in elkaar zitten en daarbij ben ik heldere en duidelijke namen nodig en heldere en duidelijke structuren.

Ik denk dus dat je het onnodig moeilijk voor jezelf aan het maken bent.

Dat betwijfel ik Ik ben een veeleisende gebruiker en alles wat ik niet in library aantref dat bouw ik zelf. Ik hou van duidelijkheid en elegantie en daarom wil ik structuren met een hele duidelijke functionaliteit zodat ik er eenvoudig over kan redeneren en uitspraken kan doen.

De concurrency library ben ik intussen wel aardig meester en daar zitten dit soort goodies (en mijn channels project) domweg niet in. Ik ben met een aantal projecten bezig waarbij ik behoefte heb aan veel meer controle dan deze library mij gaat bieden.

Volgens mij vond je het niet zo leuk dat ik je naam maar niets vond

[ Voor 15% gewijzigd door Alarmnummer op 23-08-2005 00:23 ]

[djengizz]

Pacemaker

[Alarmnummer]

djengizz schreef op dinsdag 23 augustus 2005 @ 08:18:
Pacemaker

Hmm.. een pace maker geeft 1 keer in de zoveel tijd een puls. Maw hij voert 1 keer in de zoveel tijd een task uit -> scheduler/scheduledexecutorservice En die zit al in java 5.

http://java.sun.com/j2se/...duledExecutorService.html

[ Voor 4% gewijzigd door Alarmnummer op 23-08-2005 08:27 ]

[Salandur]

Je object voert constant dezelfde taak uit, dus dat moet er wel in voor komen. Verder is het een taak die, eenmaal gestart, altijd loopt totdat je hem termineert. En dan kom je weer bij mijn naam uit van enkele posts terug, die is toch redelijk in de goede richting.

offtopic:
In die lap code van je valt me 2 dingetjes op:
1) De status wordt nooit op terminated gezet
2) De helperthreads stoppen nadat ze de taak hebben uitgevoerd

[Genoil]

/offtopic.

Sprak laatst een vriend van me die als grafisch ontwerper tussen een kluitje Java guru's werkt. Hij zegt: "Dat oeverloos gelul over testen van code is 1 ding, maar die naamgeving, daar gaan ze hard op joh!"

Jij RepetitiveNameSuggestionRejector!

[Alarmnummer]

Genoil schreef op dinsdag 23 augustus 2005 @ 09:00:
/offtopic.
Sprak laatst een vriend van me die als grafisch ontwerper tussen een kluitje Java guru's werkt. Hij zegt: "Dat oeverloos gelul over testen van code is 1 ding, maar die naamgeving, daar gaan ze hard op joh!"
Jij RepetitiveNameSuggestionRejector!

Je bent misschien even bezig om een goeie naam te bedenken, maar op lange termijn alleen maar profijt van. Dit component zal (waarschijnlijk) een belangrijke rol in gaan nemen in toekomstige projecten en er zullen veel mensen mee in aanraking komen. Daarom wil ik een goeie naam, waarbij mensen zoiets hebben van... ohja. En verder ben ik er al uit hoor Het gaat Repeater worden.

Mijn concurrency library ga ik trouwens ook opensource maken. Maar er moet op dit moment nog heel wat aan gebeuren voordat het zover is.

[ Voor 17% gewijzigd door Alarmnummer op 23-08-2005 09:22 ]

[Verwijderd]

Alarmnummer schreef op dinsdag 23 augustus 2005 @ 00:11:
Volgens mij vond je het niet zo leuk dat ik je naam maar niets vond

Nee hoor, dat maakt me niets uit, jij moet er mee werken en niet ik

[Alarmnummer]

Salandur schreef op dinsdag 23 augustus 2005 @ 08:52:
Je object voert constant dezelfde taak uit, dus dat moet er wel in voor komen.

Ik zit eraan te denken om de taak ook te kunnen wisselen en de taak ook te kunnen verwijderen (alle threads die blijven dan maffen totdat er weer een taak beschikbaar is).

Verder is het een taak die, eenmaal gestart, altijd loopt totdat je hem termineert. En dan kom je weer bij mijn naam uit van enkele posts terug, die is toch redelijk in de goede richting.

Je noemt een aantal namen. Repeat gedeelte bevalt me Manager.. tja.. dat is tegenwoordig zo`n beladen term dat ik die er liever niet voor wil gebruiken. En task erbij.. daar heb ik ook nog aan zitten denken: TaskRepeater. Maar als je naar Executor kijkt: het is Executor.. en geen TaskExecutor.

En verder zit er wel iets in het idee om vanuit de taak de Repeater te kunnen aansturen. Ik gebruik nu een runnable en misschien zou het een idee zijn om van de RepeatTask ook met een returnwaarde oid de Repeater te kunnen coordineren.

[ot]In die lap code van je valt me 2 dingetjes op:
1) De status wordt nooit op terminated gezet

Jawel hoor. Check de laatste regels van de worker maar eens.

code:

  //if this StdRepeaterService is shutting down, and there are no more workers
                //then this StdRepeaterService is terminated.
                if (_runstate == TERMINATING && _workers.isEmpty())
                    _runstate = TERMINATED;

De code is verder ook alles behalve klaar. Ik heb snel even wat in elkaar gezet om er een beetje feeling mee te krijgen. Maar er zitten nog fouten in. Bv als er geen threads zijn, dan kan het idd niet terminaten

2) De helperthreads stoppen nadat ze de taak hebben uitgevoerd
[/ot]

Hoezo? Ze blijven loopen totdat de stop flag op true is gezet.

code:

 while (!_stop) 
                _task.run();

Ik ben verder nog niet 100% uit de werking van dit object mbt wijzigingen kunnen aanbrengen in de taak die gerepeat wordt. Moet het mogelijk zijn om een huidige repeating task te stoppen? En moet het mogelijk zijn om een nieuwe taak te activeren? De kans is wel 99% trouwens dat ik dit erin ga bouwen omdat ik nu al merk dat de huidige structuur niet zo flexibel is als ik wil.

[ Voor 29% gewijzigd door Alarmnummer op 23-08-2005 10:02 ]

[Salandur]

Alarmnummer schreef op dinsdag 23 augustus 2005 @ 09:28:
[...]

Jawel hoor. Check de laatste regels van de worker maar eens.

code:

  //if this StdRepeaterService is shutting down, and there are no more workers
                //then this StdRepeaterService is terminated.
                if (_runstate == TERMINATING && _workers.isEmpty())
                    _runstate = TERMINATED;

De code is verder ook alles behalve klaar. Ik heb snel even wat in elkaar gezet om er een beetje feeling mee te krijgen. Maar er zitten nog fouten in. Bv als er geen threads zijn, dan kan het idd niet terminaten

[...]

Hoezo? Ze blijven loopen totdat de stop flag op true is gezet.

code:

 while (!_stop) 
                _task.run();

Hmmz, niet echt wakker vandaag...

Alarmnummer schreef op dinsdag 23 augustus 2005 @ 09:28:
Ik ben verder nog niet 100% uit de werking van dit object mbt wijzigingen kunnen aanbrengen in de taak die gerepeat wordt. Moet het mogelijk zijn om een huidige repeating task te stoppen? En moet het mogelijk zijn om een nieuwe taak te activeren? De kans is wel 99% trouwens dat ik dit erin ga bouwen omdat ik nu al merk dat de huidige structuur niet zo flexibel is als ik wil.

Suc6 met het verder uitwerken.

[Eelke Spaak]

Een Thread die nooit eindigt noem je toch een daemon thread? Waarom dan niet "DaemonThreadPoolExecutor"?

[Alarmnummer]

Eelke Spaak schreef op dinsdag 23 augustus 2005 @ 10:16:
Een Thread die nooit eindigt noem je toch een daemon thread?

Daar heb ik aan zitten denken. Maar een deamon service is een service die altijd voor je klaar staat om voor je te werken, maar niet een service die altijd aan het werken is. Verder kunnen threads in java idd ook deamon zijn, maar dat betekend niet dat ze altijd aan het werken zijn, maar de vm mag afsluiten als dit de enige threads zijn die nog draaien.

Waarom dan niet "DaemonThreadPoolExecutor"?

Een DeamonThreadPoolExecutor is imho een ThreadPoolExecutor waarbij iedere thread de deamon eigenschap bezit. En hierbij denk ik absoluut niet aan een taak dat herhaald blijft worden.