Verificare che il file .mat esista e non è corrotto - matlab
-
27-10-2019 - |
Domanda
Ho 2 lavoratori MATLAB indipendenti, con i primi dati di ottenere/salvare e la seconda lettura (e fare alcuni calcoli ecc.).
Per prima cosa salva i dati come file .mat sul disco rigido mentre il secondo li legge da lì. Ci vogliono ~ 20 secondi per SAVE
questi dati come .mat e 8millisec a DELETE
esso. Prima di salvare i dati, elimina prima il vecchio file e quindi salva una versione più recente.
Come può il secondo verificare che esistano i dati e is not corrupt
? posso usare exists
Ma questo non mi dice se i dati sono corrotti o no. Per ad esempio, se il secondo tenta di leggere i dati esattamente quando lo salva per la prima volta, exists
passa ma LOAD
Ti dà un errore dicendo: i dati corrotti ecc.
Grazie.
Soluzione
Non è possibile, senza un meccanismo di sincronizzazione: quando il secondo completa il suo assegno e inizia a leggere il file, prima avrebbe potuto ricominciare a scriverlo. Hai bisogno di una sorta di blocco o mutex.
Due opzioni per MATLAB di base.
Se questo è su un filesystem locale, è possibile utilizzare un file di blocco separato seduto accanto al file di dati per gestire l'accesso simultaneo al file di dati. Utilizzare gli oggetti NIO FileChannel e Filelock di Java da Matlab per bloccare il primo byte del file di blocco e usarlo come semaforo per controllare l'accesso al file di dati, quindi il lettore attende fino a quando lo scrittore è finito e viceversa. (Se questo è su un filesystem di rete, non provare questo - il blocco dei file può sembrare funzionare ma di solito non è ufficialmente supportato e nella mia esperienza è inaffidabile.)
Oppure potresti semplicemente provare/prendere il tuo load()
Chiama e mettilo in pausa qualche secondo e riprova se si ottiene un errore di file corrotto. Il formato di file .mat è tale che non otterrai una lettura parziale se lo scrittore lo sta ancora scrivendo; Otterrai quell'errore di file corrotto. Quindi potresti usarlo come una sorta di rilevamento e backoff di collisione pigro. Questo è quello che faccio di solito.
Per ridurre la finestra di contesa, prendere in considerazione l'idea di avere prima scrittura su un file temporaneo nella stessa directory, quindi utilizzare un rinominato per spostarlo nella sua destinazione finale. In questo modo il file non è disponibile solo durante un'operazione di spostamento del filesystem rapido, non i 20 secondi di scrittura dei dati. Se hai più scrittori, attaccare il PID e il nome host nel nome del file temporanea per evitare le collisioni.
Altri suggerimenti
Sembra un classico problema di condivisione delle risorse tra 2 thread (RW)
In breve, dovresti trovare un metodo di comunicazione sicura degli operai. Dai un'occhiata questo fuori.
Inoltre, prova a digitare
showdemo ('paralleldemo_communic_prof')
in matlab