cpu cycles for file operations

[Lalasa]

Hi,

Can anybody tell me how many cpu cycles File.copy would take and
how many cpu cycles File.Move would take?

CFile::Rename in C++ takes just one cpu cycle. As there is no
File.Rename in C#, I am worried about using File.copy or File.Move
which would do the same job of renaming a file but I want it done in
just one cpu cycle.

Thanks
Lalasa.

 

[Willy Denoyette [MVP]]

Hi,

Can anybody tell me how many cpu cycles File.copy would take and
how many cpu cycles File.Move would take?

CFile::Rename in C++ takes just one cpu cycle. As there is no
File.Rename in C#, I am worried about using File.copy or File.Move
which would do the same job of renaming a file but I want it done in
just one cpu cycle.

Thanks
Lalasa.

What makes you think that this can be done in one CPU cycle? There is simply
nothing at an API level that can be done in one cycle.
Basically CFile:Rename is the same as File.Move, but both take several
thousand CPU cycles from which the bulk is taken by the kernel, so we can
safely say they consume about the same amount of CPU cycles.
Just curious why this is so important to you though.

Willy.

 

[Lalasa]

Hi Willy,

There is this scenario where one application writes to a text file
and another application reads this text file. The second application
should not touch the file untill it is completely written by the first
application. So the solution we have is the first application writes to
a work file first and then after it is done renames with the right
name. The second application keeps polling the directory for the
existance of the file and as soon as it finds, it goes ahead and reads
the file.

The assumption we had was writing to a file will take a long time if
the file is too big and so writing to a temp file and renaming it
wouldnt allow the second application to touch untill the file is ready.
But once in a while we are having problems like the second application
hanging up or the second application waiting even though the file is
there and stuff like that. So I am doing research on what would be
causing this problem and the first thing I was thinking about was cpu
cycles.

If a rename in assembly language converts to a single instruction, that
means it takes a single cpu cycle. if it converts to a set of
instructions, then that means it takes mulitple cpu cycles. What you
say?

Thanks,
Lalasa.

 

[Jon Skeet [C# MVP]]

If a rename in assembly language converts to a single instruction, that
means it takes a single cpu cycle.

Sure. So are you under the impression that a file system rename
operation can occur as a single assembly language instruction? If so,
I'd be fascinated to know which instruction you think it is...

There's a big difference between an operation being atomic and it
occurring in a single CPU cycle. A file system can make atomicity
guarantees, but as far as I'm aware no CPU architecture has ever
implemented a file system as part of its instruction set...

 

[Willy Denoyette [MVP]]

Hi Willy,

There is this scenario where one application writes to a text file
and another application reads this text file. The second application
should not touch the file untill it is completely written by the first
application. So the solution we have is the first application writes to
a work file first and then after it is done renames with the right
name. The second application keeps polling the directory for the
existance of the file and as soon as it finds, it goes ahead and reads
the file.

The assumption we had was writing to a file will take a long time if
the file is too big and so writing to a temp file and renaming it
wouldnt allow the second application to touch untill the file is ready.
But once in a while we are having problems like the second application
hanging up or the second application waiting even though the file is
there and stuff like that. So I am doing research on what would be
causing this problem and the first thing I was thinking about was cpu
cycles.

If a rename in assembly language converts to a single instruction, that
means it takes a single cpu cycle. if it converts to a set of
instructions, then that means it takes mulitple cpu cycles. What you
say?

Thanks,
Lalasa.

Creating and writing to a temporary file and renaming the file when done
with it makes no sense as the second application has to wait anyway. So what
you should do is:
- Have application 1 to create the file in exclusive access mode, write the
data and close the file.
- Have the second application trying to open the same file at regular
intervals in a loop until it succeeds.

Another option (Preferred if you have control of both application) is to use
a named mutex; application 1 creates the mutex and takes ownership when the
creation process starts and releases the mutex after the file gets closed.
The second application waits for the mutex to be signaled after which the
file can be opened.

As for your "single instruction file rename" question, it seems you have no
idea at all about the complexity of a file system and what it takes to
"rename a file". As I said before, touching the filesytem for the most
simple thing like a file rename takes hundreds of thousands CPU cycles.

Willy.

 

[Mark Rance]

Creating and writing to a temporary file and renaming the file when done
with it makes no sense as the second application has to wait anyway. So
what you should do is:
- Have application 1 to create the file in exclusive access mode, write
the data and close the file.
- Have the second application trying to open the same file at regular
intervals in a loop until it succeeds.

Another option (Preferred if you have control of both application) is to
use a named mutex; application 1 creates the mutex and takes ownership
when the creation process starts and releases the mutex after the file
gets closed. The second application waits for the mutex to be signaled
after which the file can be opened.

What Mutex classes are there in .Net that work across process boundaries
like that?

-Mark

 

[Willy Denoyette [MVP]]

What Mutex classes are there in .Net that work across process boundaries
like that?

-Mark

System.Threading.Mutex

A synchronization primitive than can also be used for interprocess
synchronization.


Willy.