Design della classe Thread?

Question

Design della classe Thread?

#1 da (2 voti)
#2 da (1 voti)

6

Ho un metodo come questo nel mio codice UI:

void MyDialog::OnCommandSaveData()
{
    std::list<MyClass*> objects;
    service_->GetAll(objects);
    dataService_->SaveObjects(objects);
    AddMessage("Saved data.\n");
}

Perché questo metodo può richiedere del tempo, voglio dare il via a una discussione per farlo. Sto usando C ++ e ho intenzione di utilizzare Boost.Thread . Quindi la mia domanda è come fare al meglio. La mia comprensione è che ho bisogno di creare una funzione statica, un metodo statico o un functor che conterrà il codice precedente. Dove dovrebbe vivere, nella classe di dialogo? Sembra solo sbagliato, ma di nuovo forse no.

E quindi ho bisogno di un mutex e blocco almeno il metodo SaveObjects. Dove dovrebbe vivere il mutex e dove metto il lucchetto?

La maggior parte degli esempi di threading, come con esempi di così tante cose, non mostrano il thread nel contesto di un'applicazione reale. Mostrano un metodo principale con una funzione globale e basta. Quindi, se puoi indicarmi un esempio di una classe che gestisce il threading per un'operazione che sarebbe grandiosa.

Compro la logica nella risposta accettata a questa domanda: È" errato "/ Design errato per inserire un thread / background worker in una classe? Tuttavia, la risposta ti dice solo perché farlo, non come .

Aggiorna

Ho refactored il mio codice usando MVP (Model View Presenter) / Humble Dialog Box:

void MyDialog::OnCommandSaveData()
{
    presenter_->SaveData();
}

Quindi ora dovrò considerare l'aggiunta di multi-threading nel contesto di MVP.

UPDATE 2

Ho trovato questo articolo che parla della creazione di winform con multithreading usando MVP. È in C # quindi dovrò tradurlo in C ++ ma sembra buono:

link

Sostanzialmente si tratta di 1) creare un ThreadSafeView che è un wrapper o un proxy attorno alla tua vista che consente alla tua vista di essere aggiornata da un thread di lavoro. E 2) creando un ThreadedPresenter che consente ai metodi del presentatore di generare un nuovo thread. Mi piace molto il modo in cui questo isola il codice di threading dalla vista e dal codice del presentatore.

design c++ multithreading boost

posta User 13.10.2011 - 00:58

fonte

2 risposte

Leggi altre domande sui tag design c++ multithreading boost

Esiste un metodo leggero per descrivere i servizi Web, simile a robots.txt o sitemap.xml? Carpool architettura logica

score 2 · Answer 1

My understanding is that I need to create a static function, static method, or functor which will contain the above code. Where should this live, in the dialog class?

Non deve vivere da nessuna parte; puoi semplicemente creare un functor e passarlo al thread. Per generare un thread che esegue quella funzione membro sull'oggetto corrente, quindi esce:

boost::thread thread(boost::bind(&MyDialog::OnCommandSaveData, this));

And then I will need a mutex and lock around at least the SaveObjects method. Where should the mutex live and where do I put the lock?

Di solito è meglio tenere un mutex vicino all'oggetto che sta proteggendo; in questo caso, un membro di MyDialog .

score 1 · Answer 2

Dipende, ovviamente, da come hai progettato la tua applicazione. Se hai seguito il paradigma MVC, devi inserire quel codice da qualche parte nel modello dati o nel controller che gestisce il modello. Hai ragione che sicuramente non dovrebbe far parte di una classe di dialogo.

Pensa a cosa faresti se volessi aggiungere un altro modo per interagire con la tua applicazione. Forse dovresti aggiungere un'interfaccia della riga di comando o un'interfaccia di scripting. O magari creare un server Web in modo da potersi connettere all'applicazione da un browser web. Probabilmente vorresti essere ancora in grado di aggiungere oggetti a qualsiasi spazio di archiviazione dati utilizzato dall'app, giusto? E vorresti farlo usando lo stesso metodo di salvataggio dei dati. Quali parti dell'applicazione interagirebbe con l'ipotetica interfaccia della riga di comando? Ecco dove questo metodo appartiene.