When I make a system call from matlab in Linux, does it use a different thread?

Suppose I move a couple of files using a system call, as in:

unix('mv file1 new_path/ &');
unix('mv file2 new_path/ &');

It seems as if [rarely] file2 is being moved prior to file1. Is it possible? Could it be that the system calls are being transferred to different threads?

I'm using Matlab MCR on Amazon AWS (Centos Linux server).

Answer 1

[Jan]

unix cmd & processed the cmd in the background. The operating system is responsible then to evaluate the commands to move the files. As you have notices already, this can happen in a different order, because the two commands are different processes. It is not like you open one shell and evaluate one command after the other, but like opening two shells with one command per shell. Then the order is not exactly defined also.

[dpb]

If order is important, remove the trailing & and the calling process will wait for completion before going on...with the resultant effect the calling code waits for completion so has a delay of course...

[Omer Moussaffi]

Yes, I thought that removing the & might do that. But - I want to make sure I understand the underlying issue. As far as I understand, this solution would help only if the processes fork into different threads. Isn't there a way to control that?

[Jan]

@Omer: Yes. Using this

unix('mv file1 new_path/ &');
unix('mv file2 new_path/ &');

is the method to start two independent processes. This is the way to control this already. If Matlab should wait until the first is finished before starting the second:

unix('mv file1 new_path/');
unix('mv file2 new_path/');  % Or with appended &

Answer 2

[dpb]

(On reflection, I think my subsequent comment actually answers the question pretty-much in toto so I'll put it here instead --dpb)

It ( unix ) still starts a new process only without the ampersand the calling process waits for the spawned process to complete before continuing...with the ampersand, the caller returns immediately after starting the process and continues, thus starting the second process irrespective of the status of the other.

The unix (or system or dos, they're all interchangeable) command in Matlab maps into a system API that has as a parameter the behavior of whether to wait or not; the ampersand is the Matlab syntax used in making that call internally as to whether to set the flag or not. The spawned process is still a separate thread either way; nothing is different there, only whether your code will or will not wait for the first to complete before going on to the next.

It is not possible to schedule the two processes unalterably in order if the ampersand is used with the interface as TMW has implemented it in Matlab.

You could achieve that effect by embedding the commands in a batch file and submitting that to the OS instead of the two commands individually; then they would run sequentially in the same process.

[Walter Roberson]

"The unix (or system or dos, they're all interchangeable) command in Matlab maps into a system API that has as a parameter the behavior of whether to wait or not; the ampersand is the Matlab syntax used in making that call internally as to whether to set the flag or not. "

That is not really correct. MATLAB does not know anything about the & character for this purpose. The handling of & is entirely at the command processor. On non-Windows systems, MATLAB does the equivalent of

manipulate the file descriptors so input and output are from the right place
fork() to start a new process, process #2
in the parent process (#1), do some more file descriptor manipulation
in the parent process (#1), wait for the child to finish
in the child process (#2), do some more file descriptor manipulation
in the child process (#2), execve() the shell executable

Then, the child (#2) examines the command line to figure out what to do. If the child (#2) sees & in appropriate context, then it will decide to fork() another process, process #3, but instead of the then-parent (#2) waiting for its child process (#3), it will terminate the parent process (#2). Process #1 is waiting for that termination and will then continue.

If the child (#2) does not see & in appropriate context, it executes whatever it is intended to execute, eventually terminating, which process #1 is waiting for.

It is all up to the child process to decide how to handle & or any other indicator of process spawning. MATLAB does not, for example, need to understand all the parsing rules to decide if a & is occurring as part of a && or as part of a >& or <&- construct and MATLAB does not need to understand the six different quoting methods in shell syntax. If the user were to switch to a shell that supported the |- construct to create an independent co-process then MATLAB would not have to know that the code would return immediately. MATLAB doesn't care about that: it just waits for the child process it created, and the child process forks and exits or not according to its own rules.

[dpb]

OK, thanks for taking the time to delve more into the details, Walter... :)