[C] Ontwerpen van een library

[Neptunus]

Hallo,

Op het moment ben ik bezig met een project om een library te schrijven in C. Deze library moet in een andere thread dan de main routine zijn werk doen. Ik stel me dan bijvoorbeeld voor dat via een init functie in de library de thread wordt aangemaakt waarbinnen de library zijn werk kan doen. Alle functies in the library moeten dan gewoon aangeroepen kunnen worden, maar moeten wel uitgevoerd worden in the thread van de library.

Als je bijvoorbeeld naar de pseude code kijkt dan wordt eerst de libInit aangeroepen. Deze zou de thread voor de library moeten aanmaken. Waarna de main een aantal functions van de library aanroept met de bijbehorende parameters. Deze moeten dan uitgevoerd worden maar dan wel in de thread van de library.

Nou ik dat ongeveer wel duidelijk is wat ik wil gaan doen. Alleen nu is mijn vraag hoe realiseer ik dat de aangeroepen functies van de library inderdaad in de thread van de library worden uitgevoerd.

Ook is mijn vraag eigenlijk een beetje of deze aanpak wel goed is. Als er andere goede ideeën zijn dan hoor/lees ik ze graag.

---

Pseudo code:

C:

Int main(){
    libInit();  //init van de lib er van uitgaande dat 
                //het aanmaken van de thread gelukt is
    
    While(true){

        Printf("testingOne\n");
        LibfunctionOne(parameters);
        Printf("testingTwo\n");
        LibfunctionTwo(parameters);
        
    }
}

[Domokoen]

Ik denk dat je je eerst zult moeten inlezen in multi-threaded programmeren. Je wilt nu gelijk én een library én threads. Terwijl threads in een gewoon programma al lastig genoeg is. Om libraries multi-thread te krijgen zul je de threads volgens mij het beste gewoon in het hoofd-programma moeten aanmaken, en dan zorgen dat slechts één thread de library gebruikt. Als meerdere threads de library gaan gebruiken... let's not go there

[Neptunus]

Mr.Chinchilla schreef op zondag 17 december 2006 @ 16:37:
Ik denk dat je je eerst zult moeten inlezen in multi-threaded programmeren. Je wilt nu gelijk én een library én threads. Terwijl threads in een gewoon programma al lastig genoeg is. Om libraries multi-thread te krijgen zul je de threads volgens mij het beste gewoon in het hoofd-programma moeten aanmaken, en dan zorgen dat slechts één thread de library gebruikt. Als meerdere threads de library gaan gebruiken... let's not go there

Nou kijk het zit eigenlijk zo, ik weet nu al dat altijd maar een thread de library zal gebruiken. Dus meerdere threads zullen nooit vaker die library gaan gebruiken. Voor het gemaakt, leek het me mooi om de functies van de library te kunnen aanroepen net zoals je met normale functies doet zeg maar. Is dat nog een beetje te doen.

[alx]

Kan allemaal, maar het is een beetje vreemde constructie.
Waar heb je het voor nodig? Wat wil je doen?
Anders is het wat moeilijk om aan te geven of deze aanpak goed is. Laat staan met andere ideeen komen.

[Neptunus]

simulacrum schreef op zondag 17 december 2006 @ 17:07:
Kan allemaal, maar het is een beetje vreemde constructie.
Waar heb je het voor nodig? Wat wil je doen?
Anders is het wat moeilijk om aan te geven of deze aanpak goed is. Laat staan met andere ideeen komen.

Wat eigenlijk de bedoeling is dat een main programma een stukje hardware aanstuurd via de com poort. Voor het aansturen van deze hardware heb ik een soort van API gemaakt waarmee alle functies aangestuurd kunnen worden. Alleen moet dit in een andere thread gebeuren. Omdat het main programma ook nog andere dingen moet doen. De aansturing wel ik helemaal scheiden van het main programma.

[H!GHGuY]

Is helemaal niet moeilijk imo.

je construeert een message queue en post synchrone messages.
Ik zou wel opletten met die libinit. Ik ken de reden niet waarom maar als je boost gebruikt (www.boost.org) dan staat bij de thread library duidelijk dat je geen threads mag aanmaken in de dll main.

C++:

class IMessage
{
   private:
   friend class CMsgQueue;

   Wait() { m_Semaphore.Down(); }
   Go() { m_Semaphore.Up(); }
   CSemaphore m_Semaphore;
}

class CSomeMessage : public IMessage
{
}

class CMsgQueue
{
   public:
   void PostMessage(IMessage* msg)
   {
     {
        CScopedLock lock(m_Lock); // een of ander class die scoped locking voorziet
        m_Messages.push(msg);
        m_Semaphore.Up();
     }
     msg->Wait();
   }
   void HandleMessahe(IMessage* msg)
   {
       // doe iets
      msg->Go();
   }
   void HandleMessages()
   {
      while (notExiting)
      {
         m_Semaphore.Down();
         CScopedLock lock(m_Lock);
         HandleMessage(queue.front());
         queue.pop_front();
      }
   }
   private:
   CLock m_Lock;
   CSemaphore m_Semaphore;
   std::queue<IMessage> m_messages;
}

dit stukje code zou je al heel ver moeten helpen.

Of wat je wil nuttig is, zoals anderen al aanhalen, is nog maar de vraag.

[ Voor 10% gewijzigd door H!GHGuY op 17-12-2006 17:26 ]

[Neptunus]

H!GHGuY schreef op zondag 17 december 2006 @ 17:23:
Is helemaal niet moeilijk imo.

Of wat je wil nuttig is, zoals anderen al aanhalen, is nog maar de vraag.

Ik moet C gebruiken, onder tussen heb ik al iets meer aangegeven wat de bedoeling is ongeveer. Ik zal ook nog eens goed nadenken over het ontwerp, als jullie nog goede ideeen hebben...

[farlane]

Waarom ga de library een thread laten maken? Waarom laat je niet het hoofdprogramma functies aanroepen vanuit een andere thread dan de main thread?

[alx]

Een functie laten callen kan idd door een msg in een gedeelde queue te zetten. De lib thread blockt op die queue (sema down ofzo) en doet calls via een lookup/switch of direct als de msg de functie ptr bevat. Maar dat is slechts het halve werk:
- Hoe geef je parameters door? Iedere functie heeft een andere set parameters. Dat zul je dan allemaal moeten "unificeren", zodat je 1 msg type krijgt.
- Hoe weet de main thread wanneer de call klaar is en hoe wordt de return waarde weer beschikbaar voor de main thread? Weer een msg queue de andere kant op?

Ik krijg het idee dat het simpeler kan. Dit proggen is eigenlijk een nieuwe async interface bouwen. Dat zou nodig zijn, omdat, als ik het goed begrijp (klopt dat?):
- De main thread meteen iets anders moet doe na een call, terwijl
- Het uitvoeren van sommige van die API functies enige wachttijd met zich meebrengt (bv blocking read).

Gaat het om het wachten op response na een request aan je COM device of zoiets? Kun je dan niet met de enige thread een request doen; een alarm/timer zetten, gaan rekenen en als het alarm afgaat, _non-blocking_ checken of er response is? Zo niet, weer een alarm zetten en doorrekenen.
Als je die call zelf kan doen, heb je bovenstaande problemen (para passen, rv ontvangen) allemaal niet en geen extra thread + sync nodig. Easy does the trick