[C++]Work queue implementatie

[Hmail]

Ik heb C++ in de titel gezet, maar de taal zou volgens mij niet echt uit moeten maken. Anyway, ik ben bezig met het onder de knie krijgen van concurrency en heb nu een basis idee bedacht waarbij een vast aantal threads een directorystructuur doorzoeken. Iedere thread leest een directory, en voegt iedere nieuw gevonden directory toe aan de workqueue. Zodra dit klaar is moeten de threads stoppen, joinen en is het programma rond.

In mijn hoofd leek het zo makkelijk

Dit is wat ik nu heb:

C++:

void ThreadManager::iAmRunning(  )
{
    pthread_mutex_lock( &this->thread_mutex );
    if( this->waitingthreads > 0 )
        this->waitingthreads--;

    this->runningthreads++;

    this->all_work_done = false;
    pthread_mutex_unlock( &this->thread_mutex );
}

void ThreadManager::iAmWaiting(  )
{
    pthread_mutex_lock( &this->thread_mutex );

    if( this->runningthreads > 0 )
        this->runningthreads--;

    this->waitingthreads++;

    if( this->waitingthreads >= NUM_THREADS )
    {
        this->all_work_done = true;
        pthread_cond_broadcast( &this->work_done_cond );
    }
    else
        this->all_work_done = false;

    pthread_mutex_unlock(&this->thread_mutex);
}

Directory* ThreadManager::GetWorkItem()
{
    this->iAmWaiting( );
    pthread_mutex_lock( &this->directory_mutex );
    while( this->workqueue.size() == 0 )
    {
        if (this->all_work_done)
        {
            pthread_mutex_unlock(&this->directory_mutex);
            return NULL;
        }
        
        pthread_cond_wait( &this->work_done_cond, &this->directory_mutex );
    }
    this->iAmRunning( );
    Directory* ret = this->workqueue.back();
    this->workqueue.pop_back();
    pthread_mutex_unlock( &this->directory_mutex );
    return ret;
}

Toen ik dit bericht aan het schrijven was ontdekte ik al de oorzaak van een deadlock waarom ik dit topic wilde maken, (niet de eerste keer dat dat gebeurd ), regel 41 ontbrak nog, maar ik ben toch nog wat onzeker over de code.

Ik meen ook daarna nog een deadlock gehad te hebben toen ik dit zonder debugger draaide, maar na diverse pogingen met grote en kleine hoeveelheden threads en directories krijg ik dat niet geproduceerd, ook niet na het toevoegen van wat sleep calls in GetWorkItem(). Nu ga ik dus aan mezelf twijfelen, maar misschien dat iemand hier een mogelijkheid voor een deadlock ziet?

Ook ben ik geïnteresseerd in jullie meningen. Is dit een goede implementatie van een Work Queue? Ik heb het grofweg gebaseerd op Multithreaded Work Queue in C++, met dus de toevoeging dat threads zelf items in de work queue zetten en een flag zetten als het werk gedaan is. Wat zijn jullie ideeën hierover?

[Zoijar]

Zoek eens op "producer consumer" dan vind je tiental standaard oplossingen in alle talen en manieren.

Die oplossingen gewoon 1-op-1 kopieren; elke regel die je zelf toevoegt zonder er veel verstand van te hebben introduceert iha races en deadlocks.

[Hmail]

De term komt me inderdaad wel bekend voor, ben ik natuurlijk al een aantal keren tegengekomen, maar is dat in dit geval van toepassing? Iedere thread levert namelijk weer nieuw work en het is dus niet echt gescheiden tussen thread A levert alleen, en thread B consumeert..

Ik zal er nog eens wat dieper op inlezen, thanks

[Caelorum]

Je hebt ook multi-producer/multi-consumer queues die je kan gebruiken. Boost heeft er bijv. een lock-free variant van. De concurrent queues van Intel TBB zijn dat ook. Wellicht dat je nog kan kijken naar hoe dat is opgezet.

[.oisyn]

Overigens, los van het feit dat het een goede oefening is ga je verder waarschijnlijk geen voordeel behalen aan het met meerdere cores uitlezen van een dir structuur

[Caelorum]

Of je moet veel disks hebben?

[Hmail]

Caelorum schreef op zondag 18 januari 2015 @ 19:18:
Je hebt ook multi-producer/multi-consumer queues die je kan gebruiken. Boost heeft er bijv. een lock-free variant van. De concurrent queues van Intel TBB zijn dat ook. Wellicht dat je nog kan kijken naar hoe dat is opgezet.

Thanks! Dat was een term waar ik naar op zoek was. Dat had ik zelf ook nog wel kunnen bedenken Ik ga me er eens meer in verdiepen.

.oisyn schreef op zondag 18 januari 2015 @ 19:21:
Overigens, los van het feit dat het een goede oefening is ga je verder waarschijnlijk geen voordeel behalen aan het met meerdere cores uitlezen van een dir structuur

Ik laat me niet tegenhouden door de laws of physics
Het is idd puur bedoeld als oefening, en het lijkt voornamelijk een vertraging te zijn (aanmaken van threads, wachten op locks, etc). Op de lange termijn ben ik bezig een backup client te schrijven die praat met een web service, en ik vraag mezelf zelfs af of ik uberhaupt iets van deze kennis ga kunnen gebruiken in het hele systeem, maar nieuw terrein leren is altijd leuk

[Zoijar]

.oisyn schreef op zondag 18 januari 2015 @ 19:21:
Overigens, los van het feit dat het een goede oefening is ga je verder waarschijnlijk geen voordeel behalen aan het met meerdere cores uitlezen van een dir structuur

Hehe, ja, of je nou in je eentje of met z'n vieren op die draaiende plaat staat wachten maakt idd niet zo veel uit

[Caelorum]

Met zijn vieren is veel gezelliger ^^