[C++] esperti

[trallallero]

Allora, ho in ballo un potenziale colloquio con una banca in Svizzera che mi potrebbe cambiare la vita e l'agenzia inglese di tramite mi chiede ciò:

4. Have you multithreaded programming experience.?
If so, any experience of STL , or RogueWave.

fino alla domanda 3 ok, ma qui non so cosa rispondere.
Cosa deve sapere uno per poter dire: si ho esperienza in multithreaded programming ?
Perchè in effetti io ho esperienza di programmazione concorrenziale in C, quindi più processi clonati, non threads in C++.
Poi RogueWave non so neanche cosa sia, STL lo conosco poco ma non mi sembra così complesso.
Insomma, si può imparare velocemente 'sta benedetta multithreaded programming ? se si, come ?
Grazie

[yorkeiser]

Non conosco il multithreading in C++ ma lo utilizzo da diverso tempo in Java, e ti dico che utilizzarlo è piuttosto semplice se hai un minimo di concezione di cosa sia un oggetto e la concorrenzialità dei processi. Chiaramente dipende, se poi ti richiedono tecniche assurde che hanno appena inventato al MIT è un altro conto, ma, secondo me, vai liscio liscio. Non credo ci possano essere differenze tremende tra i due linguaggi da questo punto di vista; magari, essendo il C++ un linguaggio di livello leggermente più basso, il multithreading avrà qualche funzionalità in più. Per STL e RogueWave non posso aiutarti, devo ammettere che non ho la minima idea di cosa si stia parlando

[vizzz]

RogueWave mai sentito per il resto niente che in un paio di giorni di sbattimento di testa non si possa imparare secondo me.
io darei un occhio ai worker thread.
ciao

[trallallero]

si, concordo che sicuramente imparare la teoria n 2 giorni si può fare, avendo alle spalle 8 anni di esperienza. Come quando ho imparato a suonare l'armonica avendo 10 anni di chitarrista solista blues, è stata una passeggiata Ma la pratica è un'altra cosa e soprattutto il colloquio, se ci sarà, è ... in inglese
Dove posso dare velocemente una lettura con qualche esempio ?
Grazie delle risposte

[trallallero]

dimenticavo ... è un pò che lavoro qualche volta in C, sennò PL/SQL ma di solito test alfa, permessi beta, telefonate per documentazione inesistente, valutazione rischio beta, burocrazia, burocrazia, burocrazia, burocrazia
Me ne vojo annà!!!!

[vizzz]

mi sono scontrato una volta con PL1, e stavo per piangere davvero ehehe
prova a dare un occhio a questo:http://www.codeproject.com/threads/g...hreadclass.asp

[trallallero]

Originariamente inviato da vizzz

RogueWave mai sentito per il resto niente che in un paio di giorni di sbattimento di testa non si possa imparare secondo me.
io darei un occhio ai worker thread.
ciao

worker thread ? cioè ?

[trallallero]

Originariamente inviato da vizzz

mi sono scontrato una volta con PL1, e stavo per piangere davvero ehehe
prova a dare un occhio a questo:http://www.codeproject.com/threads/g...hreadclass.asp

grazie ma in effetti non ho specificato ... Non M$ ma Unix

[trallallero]

vabbè, ho trovato questo:
http://docs-pdf.sun.com/816-5137/816-5137.pdf
grazie delle risposte, prevedo flussi incontrollati di adrenalina domani

[tomminno]

Originariamente inviato da trallallero

Allora, ho in ballo un potenziale colloquio con una banca in Svizzera che mi potrebbe cambiare la vita e l'agenzia inglese di tramite mi chiede ciò:

fino alla domanda 3 ok, ma qui non so cosa rispondere.
Cosa deve sapere uno per poter dire: si ho esperienza in multithreaded programming ?

In teoria l'aver affrontato le problematiche di un programma con più thread, con relativa sincronizzazione e gestione.

Perchè in effetti io ho esperienza di programmazione concorrenziale in C, quindi più processi clonati, non threads in C++.

Le librerie per thread che conosco sono tutte in C (PThreads, Win32)

Poi RogueWave non so neanche cosa sia, STL lo conosco poco ma non mi sembra così complesso.
Insomma, si può imparare velocemente 'sta benedetta multithreaded programming ? se si, come ?
Grazie

RogueWave mai sentito, per l'STL, beh come non usarla parlando di C++?

[trallallero]

Originariamente inviato da tomminno

In teoria l'aver affrontato le problematiche di un programma con più thread, con relativa sincronizzazione e gestione.

appunto, siccome non l'ho mai fatto saró sincero e diró che so qualcosa ma non ho esperienza. Meglio che una figuraccia dopo.

Originariamente inviato da tomminno

Le librerie per thread che conosco sono tutte in C (PThreads, Win32)

infatti sto guardando quelle

Originariamente inviato da tomminno

RogueWave mai sentito, per l'STL, beh come non usarla parlando di C++?

mai avuto l'esigenza. Ho modificato programmi che usano STL, ma non l'ho mai usato per programmi miei.

[tomminno]

Originariamente inviato da trallallero

appunto, siccome non l'ho mai fatto saró sincero e diró che so qualcosa ma non ho esperienza. Meglio che una figuraccia dopo.

Mai usato i socket?

mai avuto l'esigenza. Ho modificato programmi che usano STL, ma non l'ho mai usato per programmi miei.

Mai usato string, stream, vector,...?

[trallallero]

Originariamente inviato da tomminno

Mai usato i socket?

si ma per sistemi server-client, é diversa la cosa. Un conto é clonare figli un conto gestire threads che comunicano tra loro e magari usano shared memory, stati etc ...

Originariamente inviato da tomminno

Mai usato string, stream, vector,...?

si ma solo per modificare programmi di altri. Sicuramente sbaglio ma per quelle cose uso ancora il C. Non mi sembra diano un gran vantaggio, per me il C++ é OO, class

[tomminno]

Originariamente inviato da trallallero

si ma per sistemi server-client, é diversa la cosa. Un conto é clonare figli un conto gestire threads che comunicano tra loro e magari usano shared memory, stati etc ...

Intanto è una tipica applicazione multithread. Magari devi evitare che più thread scrivano sul socket in parallelo compromettendo la corretta comunicazione dei dati.

si ma solo per modificare programmi di altri. Sicuramente sbaglio ma per quelle cose uso ancora il C. Non mi sembra diano un gran vantaggio, per me il C++ é OO, class

Sai è tanto più comodo vector<string> che non char **.
Praticamente te usi il "C con le classi".

[trallallero]

Originariamente inviato da tomminno

Intanto è una tipica applicazione multithread. Magari devi evitare che più thread scrivano sul socket in parallelo compromettendo la corretta comunicazione dei dati.

si, diciamo che potrei imparare l'argomento in fretta vista l'esperienza in server side (Edison Tel penso stia ancora usando il progetto fatto da me) ma vallo a spiegare al cliente

Originariamente inviato da tomminno

Sai è tanto più comodo vector<string> che non char **.
Praticamente te usi il "C con le classi".

beh proprio cosí no, ma quasi
Infatti sto pensando di sfruttare il tempo libero per rinforare un pó sto C++ ... in fondo mi manca solo quello per affrontare l'Europa

[cionci]

Originariamente inviato da tomminno

RogueWave mai sentito, per l'STL, beh come non usarla parlando di C++?

Credo che ci sia qualche problemino di concorrenza a condividere container STL fra thread... Sinceramente non ho mai approfondito la cosa e quando mi è servito ho sempre cercato di limitare i danni ad un livello più alto...

[trallallero]

se qualcun altro é interessato all'argomento (che avrei anche potuto mettere nel titolo ) ho trovato questo:
http://www.llnl.gov/computing/tutorials/pthreads/

[jappilas]

Originariamente inviato da trallallero

se qualcun altro é interessato all'argomento (che avrei anche potuto mettere nel titolo ) ho trovato questo:
http://www.llnl.gov/computing/tutorials/pthreads/

in tal caso c'è un paper che ho trovato che ti potrebbe interessare ( why posix threads are unsuitable for C++ )

[trallallero]

Originariamente inviato da jappilas

in tal caso c'è un paper che ho trovato che ti potrebbe interessare ( why posix threads are unsuitable for C++ )

Accesso Negato

Utente non autorizzato all'accesso di questo sito.
Questo si verifica nei casi in cui si tenta di accedere ad un sito web bloccato in base alle policy aziendali.

Per ricevere assistenza, contattare l'help desk.

vabbé, grazie, scaricheró da casa che é meglio, qui sono in un gulag

[cionci]

Comunque per quanto riguarda il thread safety della STL: è un vero casotto... In pratica conviene sempre gestire la risorsa come una normale risorsa condivisa sia in problemi di lettura/scrittura, sia in problemi di sola lettura multipla...in quanto il livello di thread safety della STL non è definito dallo standard, ma dipende dalla singola implementazione.

Quindi attenzione ad usare gli iteratori...bisogna prima assicurarsi la mutua esclusione sul container...