No se puede, sin algún mecanismo de sincronización - por segunda vez completa su cheque y comienza a leer el archivo, FIRST podría haber comenzado a escribirlo nuevamente. Necesitas algún tipo de bloqueo o mutex.
Dos opciones para la base Matlab.
Si se trata de un sistema de archivos local, podría utilizar un archivo de bloqueo separado al lado del archivo de datos para administrar el acceso concurrente al archivo de datos. Utilice los objetos NIO FileChannel y FileLock de Java desde Matlab para bloquear el primer byte del archivo de bloqueo y usarlo como un semáforo para controlar el acceso al archivo de datos, de modo que el lector espere hasta que el escritor finalice y viceversa. (Si esto está en un sistema de archivos de red, no intente esto - el bloqueo de archivos puede parecer que funciona, pero generalmente no es compatible oficialmente y en mi experiencia no es confiable.)
O simplemente podría probar/capturar su load() llame y póngalo en pausa unos segundos y vuelva a intentarlo si obtiene un error de archivo corrupto. El formato de archivo .mat es tal que no obtendrá una lectura parcial si el escritor todavía la está escribiendo; obtendrá ese error de archivo corrupto. Entonces podrías usar esto como un tipo perezoso de detección de colisión y retroceso. Esto es lo que suelo hacer.
Para reducir la ventana de contención, considere tener FIRST escribir en un archivo temporal en el mismo directorio, y luego usar un rename para moverlo a su destino final. De esta forma, el archivo solo no estará disponible durante una operación de traslado rápido del sistema de archivos, no a los 20 segundos de escritura de datos. Si tiene varios escritores, pegue el PID y el nombre de host en el nombre del archivo temporal para evitar colisiones.
¿Está utilizando la Parallel Computing Toolbox? –