Timers and thread safety
19 vues (au cours des 30 derniers jours)
Afficher commentaires plus anciens
I don't understand how to assure thread safety if timer callbacks can be initiated between any two lines of code. How do I prevent a timer from interrupting a function/method which puts an object, that the timer uses, in an intermediate state?
0 commentaires
Réponses (3)
Walter Roberson
le 9 Déc 2011
The key point to remember about mutex files on network drives is that they usually do not work properly.
Most network file systems work by each system keeping a cache of recently-requested information of interest on the remote file system, and when a program queries for the information, if the information is in cache and the cache is young enough then the information is served from the cache; if the information is not in the cache or it has expired in the cache then the information is fetched from the remote system.
When a program checks the contents of a remote directory (to determine a file does or does not exist) it is thus prone to getting whatever is within the directory cache, rather than getting the "current" information. This can cause it to believe that it still has an active semaphore that it no longer has (and thus to write when it should not), or can cause it to believe that a lock from another process does not exist when it in fact has been created but the local information has not been conveyed yet (thus leading it to go ahead and assert a semaphore it is not entitled to and to start reading or writing a file, leading to inconsistencies and "race conditions" with other processes.)
Network file system servers usually also do not allow other systems to register "interest" in particular files or directories in such a way that the updated information might be "pushed" from the server to the system with the interest.
Even on a single system with no network file system, there are inherent race conditions in the common technique of "Check to see whether the semaphore file exists. If it does, wait a bit until it goes away; if it does not exist, request to create it". Network file systems magnify these inherent problems.
In order for a semaphore file to be created properly, the local system (and any network file system involved) must support an "atomic operation" (which means that it is indivisible at the kernel interrupt level) which creates a file only if it does not exist and returns an error if it did exist -- combining both parts of the test without any possibility that something could happen in between the two parts. This kind of atomic filesystem operation is available on all systems that support POSIX (which includes all Linux, all Mac OS, and XP SP2 and all later MS Windows) and is a mandatory part of NFS (Network File System) version 2 and later (a version which has been around for many years.)
Unfortunately, the underlying atomic file system operation mentioned is not available within MATLAB without using mex. MATLAB makes available most I/O operations from the C standard library, but C standard library is based upon the (FILE *) buffered file abstraction rather than on fundamental OS operations. The C I/O library opens files (and devices) using fopen() calls. The fundamental atomic file system operation available on the systems mentioned above, is coded as a call to open() (not fopen()!) with the flags O_CREAT|O_EXCL . It is a POSIX standard OS call, but unfortunately not one that MATLAB provides an interface to.
0 commentaires
Jan
le 24 Nov 2011
Did anybody claim, that the timer functions are thread safe?
You will need the same mechanism as in other languages: A mutex has to block the concurrent access of an object.
Daniel, I assume you want to find this explained explicitely in the documentation. Me too.
[EDITED: ] A too simple mutex - DO NOT USE THIS!
function main
global S
S.mutex = 0;
S.data = rand(10);
myProcessing;
end
function myProcessing(varargin)
global S
mutexCaught = false;
while ~mutexCaught
S.mutex = S.mutex + 1;
% If another thread sets exactly here S.mutex to 2, both
% threads are locked.
if S.mutex == 1
mutexCaught = true;
else
pause(0.02);
end
end
%
% do the processing with S.data
%
% Release the mutex:
S.mutex = 0
end
3 commentaires
Jan
le 25 Nov 2011
I'm going to bed now. Perhaps I get a more stable idea tomorrow.
Walter has some experiences with mutex files on network drives. Perhaps he has a secure solution.
I guess, that the timer callback can be executed only, if a line is finished. Then the commands for changing teh mutex value and checking it afterwards can be moved to a single line. But this must be confirmed by a Matlab developper...
Voir également
Catégories
En savoir plus sur Call MATLAB from C dans Help Center et File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!