[c++] threads, hoe maak ik een inputlistener?

Pagina: 1
Acties:

  • 12_0_13
  • Registratie: April 2004
  • Laatst online: 12-02 13:19
Hallo,

Ik wil graag in c++ een soort eventlistener, (zie java actionlistener bijv) maken. Dus dat verschillende objecten events kunnen sturen naar het listener object.

Nou zit ik een beetje met het probleem dat ik niet goed weet hoe ik dit moet ontwerpen. Ik heb nu alle dingen die events kunnen veroorzaken in aparte threads (van de pthreads lib) gestopt, zodat het listener object gewoon door kan blijven listenen. Maar ik zit een beetje met het wachten op events. Ik kan wel een busy-wait maken, maar erg netjes is dit niet. Met Sleep kan het ook, maar zan dit je meteen weer aan windows vast en dat wil ik ook niet.

Wat ik nu heb lijkt ene beetje op de windows message queue, alleen vreetie met busy waiting wel 100% processor tijd en dat wil ik eigenlijk niet

C++:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
class Listener
{
public:
    processEvent(Event const & e);
    startListening();
}

Listener::processEvent(Event const & e)
{
    //doe iets met het event;
}
Listener::startListening()
{
    buttoninputthread.setListener(this);  //beetje pseudo code :)
    while(42) // ;)
    {}
}


Ik heb wel op google gezocht, maar het is erg lastig om zoiets te vinden (kom wel HEEL veel java stuff tegen, maar daar heb ik niet zoveel aan)

Is er een soort standaard oplossing voor dit probleem? OF heeft iemand goeie tips?

  • whoami
  • Registratie: December 2000
  • Laatst online: 16:53
Kan je niets doen met het Observer design pattern?

Daar heb je 1 'subject' en verschillende 'observers'. Bij jou zou het dan wel omgekeerd moeten zijn: verschillende subjects die dezelfde observer hebben.

https://fgheysels.github.io/


  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

ZOek ff op semafoor dan kom je er wel uit.

[edit]
Als je een event queueue gaat maken waarin de events gestored worden, kunnen event veroorzakende threads gewoon hun event posten in de event queue en daarna kunnen ze weer verder gaan met hun werkzaamheden. Achter die event queue laat je een worker luisteren naar een semafoor. Op deze manier gaat de worker alleen werken als er events in de eventqueue zitten. Zijn er geen events in de queue? Dan ligt de worker gewoon fijn te slapen.

Is trouwens wel redelijk concurrency-basic zeg. Heb je dit niet gehad op school?

[ Voor 87% gewijzigd door Alarmnummer op 26-05-2004 11:09 ]


  • 12_0_13
  • Registratie: April 2004
  • Laatst online: 12-02 13:19
In principe doe ik dat toch al? Als je inplaats van processEvent () leest: Update( ) en in plaats van het inkomende event het Subject, dan heb je het observer pattern.

Het probleem zit hem in de busy wait die in de Observer zit, immers zal ergens moeten worden gewacht tot een Update wordt geroepen?

Aangepaste code:
C++:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
class Listener
{
public:
    update(Event const & e);
    startListening();
}

Listener::update(Event const & e)
{
    //doe iets met het event;
}
Listener::startListening()
{
    buttoninputthread.setListener(this);  //beetje pseudo code :)
    mouseinputthread.setListener(this);

    while(42) // ;)
    {
    }
}


Waarbij beide inputthreads de state van de buttons/mouse pollen. Dit moet later ook veranderbaar zijn naar bijvoorbeeld networkinputthread etc.

  • MSalters
  • Registratie: Juni 2001
  • Laatst online: 09-04 22:08
Je wacht op de semafoor; dat is geen busy wait.

Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein


  • 12_0_13
  • Registratie: April 2004
  • Laatst online: 12-02 13:19
Ok ik probeer het even :)


Owwww DOH DOH DOH... het is natuurlijk gewoon het producer-consumer probleem. Dat heb ik inderdaad wel eens geleerd.

[ Voor 168% gewijzigd door 12_0_13 op 26-05-2004 11:41 ]

Pagina: 1