Informazioni sul servizio
TradottoSono un ingegnere in informatica concorrente e ho lavorato con il linguaggio Occam per molti anni, che è nato dalla teoria di Hoare sui processi sequenziali comunicanti. Di solito ricevo uno dei due tipi di compiti. O c'è un vecchio sistema transputer che controlla ancora un'installazione, uno scanner o un banco di prova, e nessuno riesce più a capire il suo codice. Oppure si sta pianificando un nuovo progetto in cui è necessaria una parallelismo senza deadlock che può essere dimostrato corretto, piuttosto che il solito groviglio di thread e mutex. Affronto entrambi i tipi di lavoro. Per i sistemi legacy, leggo il codice sorgente di Occam 2, ricostruisco la rete di processi su carta, descrivo ogni canale e le costruzioni PAR e ALT, e poi mantengo l'operazione su emulatori di transputer o riscrivo la logica in occam-pi, in C con una libreria CSP, o in canali Go, preservando la semantica di sincronizzazione esatta. Per i nuovi sistemi, modello tutto come processi sequenziali che comunicano attraverso canali tipizzati, dimostro l'assenza di deadlock e livelock, e fornisco codice pulito e ben commentato con un ambiente di test. Una consegna tipica include una mappa di processo documentata, codice sorgente funzionante sotto controllo di versione, build e simulazione, così come un breve rapporto sul modello di concorrenza affinché il tuo team possa mantenerlo facilmente. La correttezza è per me più importante di trucchi ingegnosi: i canali rimangono non bufferizzati senza una buona ragione, le guardie ALT vengono controllate, e lo stato condiviso lo progetto in modo che semplicemente non esista. Che debba rivitalizzare un modulo transputer ostinato o costruire una simulazione parallela da zero, porterò a termine il lavoro dall'analisi alla consegna testata. Descrivi cosa fa il sistema, su quale hardware o runtime gira, e quanto codice vecchio è sopravvissuto, e valuterò onestamente l'ambito del lavoro prima di iniziare.
