• Enrico Denti
    Enrico Denti, 17/03/2010 18:26

    Obiettivo:
    - reingegnerizzazione architetturale del motore di tuProlog per supportare il parallelismo

    Cosa ha fatto:
    - EngineManager diventa astratta
    - ThreadManager implementa EngineManager e si assume la responsabilità di gestire la risoluzione di una query
    - è ThreadManager a reindirizzare le chiamate verso l?istanza giusta di BasicEngineManager
    - Sincronizzazione dell?ambiente di esecuzione (Tutte le operazioni svolte dai Manager dovranno essere sincronizzate o rientranti) e delle esecuzioni parallele dei thread (Corretta cooperazione dei thread e prevenzione di deadlock ed interferenze)
    - creazione di thread con thread_create(+Goal, -Id) o thread_execute(+Goal, -Id) [quest?ultima backtrackabile]
    - cooperazione fra thread con thread_next(+Id), thread_read(+Id, Res), thread_join(+Id, Res)
    - invio e ricezione di messaggi tramite code sincronizzate (una per thread), con predicati di ricezione sia bloccanti sia non bloccanti, nonché possibilità di ricezione del messaggio condizionata all?unificazione con un template
    - controllo accessi fra thread per gestire possibili interferenze (rimozione di soluzioni attese, rimozione di msg dalla coda di un altro thread) à conseguente definizione di thread pubblici, protetti, privati con diversi diritti
    - Sincronizzazione esplicita con creazione e gestione di mutex  (da tuprolog)

    Cosa manca:
    - concetto di teoria privata
    - strumenti di sync evoluti (regioni critiche, monitor, etc)
    - parallelismo implicito (esplorazione parallela di sottogoal)

2008 © aliCE Research Group @ DEIS, Alma Mater Studiorum-Università di Bologna
0.2