Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.development.apps > #54

Re: mkdir() and thread safety()

Show all headers | View raw

On Mar 28, 5:59 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> David Schwartz <dav...@webmaster.com> writes:
> > On Mar 25, 5:56 pm, mkaushik <mayank.ute...@gmail.com> wrote:
>
> >> I have two threads, each tries to create a directory of the same name
> >> at the same location using mkdir(). The threads need to be oblivious
> >> of each others' existence. Do I have to worry about concurrency when I
> >> use mkdir() to create this directory? Or will mkdir() always return
> >> success in one thread and EEXIST in the other?
>
> > This will almost certainly happen on every system I can imagine.
> > However, it is not guaranteed. So long as the directory didn't exist
> > before you called 'mkdir' and did exist during the call, the standards
> > permit 'mkdir' to return success.
>
> > This could happen in the following case:
>
> > 1) The implementation confirms the directory does not yet exist.
> > 2) The implementation sends a command to the underlying filesystem to
> > make the directory.
> > 3) The underlying filesystem fails or connectivity to it is lost
> > before the reply to the command is read.
> > 4) The implementation determines that the directory does now exist. It
> > does not know if it was created as a result of its operation in step 2
> > or not.
> > 5) The implementation returns success as that's preferable in this
> > case. (And will be correct most of the time.)
>
> > This could happen on a network filesystem that uses a stateless
> > protocol over an unreliable medium.
>
> .. provided implementation is completely broken because the
> responsible people didn't understand what a TOCTOU race actually is:
> The check in step 1 is completely useless because it communicates
> nothing about the state of the filesystem at the time when 'the
> command' will be executed. Step 4 is outright broken: The fact that a
> directory came into existence by some means after step 1 communicates
> nothing about the result of the command sent in step 2. And it is
> certainly not 'preferable' to fabricate 'assumptions' in code based on
> the pretext that they are likely going to be correct. Insofar this is
> concerned, the implementation could as well just always return success
> since this will be 'correct most of the time'.
>
> Also, the UNIX(*) standard demands that mkdir is supposed to fail with
> EEXIST when the named file already existed. This is not possible when
> mkdir is not an atomic operation.

Thanks for the answers everyone!

Back to comp.os.linux.development.apps | Next — Next in thread | Find similar

Thread

Re: mkdir() and thread safety() mkaushik <mayank.utexas@gmail.com> - 2011-03-30 00:37 -0700
  Re: mkdir() and thread safety() Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-03-30 15:44 +0100

csiph-web