Hi,
I had post a simillar message before.
Thanks for the replay from Albert D. Cahalan. But i found some results
confusing me.
For example, process 1 and process 2 run concurrently and execute the
following system calls.
rename("/usr/hybrid/cfg/data","/usr/mytemp/data1"); /*for process 1*/
----------------------------------------------------------------
rename("/usr/mytemp/data1","/usr/test");/* for process 2*/
----------------------------------------------------------------
It is possible that context switch happens when process 1 is look ing up
the inode for "/usr/mytemp/data1" or the inode for "/usr/hybrid/cfg/data".
It will result in diffrent behaviour for process 2 and confuses the
application.
If so,how does Linux solve?
Thanks.
Warren
On Mon, 9 Apr 2001, warren wrote:
>
>
> Hi,
> I had post a simillar message before.
> Thanks for the replay from Albert D. Cahalan. But i found some results
> confusing me.
> For example, process 1 and process 2 run concurrently and execute the
> following system calls.
>
> rename("/usr/hybrid/cfg/data","/usr/mytemp/data1"); /*for process 1*/
>
> ----------------------------------------------------------------
>
> rename("/usr/mytemp/data1","/usr/test");/* for process 2*/
> ----------------------------------------------------------------
> It is possible that context switch happens when process 1 is look ing up
> the inode for "/usr/mytemp/data1" or the inode for "/usr/hybrid/cfg/data".
> It will result in diffrent behaviour for process 2 and confuses the
> application.
> If so,how does Linux solve?
Solves what, precisely? Result depends on the order of these calls. If
you don't provide any serialization - you get timing-dependent results
you were asking for. What's the problem and what behaviour do you expect?
Besides, what's the difference caused by the moment of context switch?
In article <000201c0c0a4$eb5c7b10$321ea8c0@saturn> you wrote:
> rename("/usr/hybrid/cfg/data","/usr/mytemp/data1"); /*for process 1*/
> rename("/usr/mytemp/data1","/usr/test");/* for process 2*/
Rename syscall is expected to be atomic on unixoid systems. And I dont know of
a case where a problem is, besides if you use some network file system, where
nobody can realy gurantee anything (well kidding, but it is harder than on a
local one).
The second rename may see the result of the first rename or the original state
before the first rename. It will not see any half-state or locked nodes.
Greetings
Bernd