[prev in list] [next in list] [prev in thread] [next in thread] 

List:       imap
Subject:    Re: imap and nfs
From:       "Bayard G. Bell" <bbell01 () emory ! edu>
Date:       1999-11-30 18:41:42
[Download RAW message or body]

Hugh,
	Thank you for the explanation.  This all makes pretty good sense to me
on the surface.  I was hoping you could indulge me further: As an admin,
I'm curious as to how a composite (pardon the neologism -- I lack the
technical language in this area) atomic system call (vs. a non-atomic
composite system call) might show up in a truss.
	I bugged a programmer friend about this, and she told me that the
relevant distinction in this case may not be between atomic and
non-atomic but between blocking and non-blocking system calls.  I'm not
sure I understood this distinction and was hoping someone could explain
this and perhaps even tell me whether this distinction is in fact
relevant.

-Bayard Bell
Emory University

Hugh McIntyre wrote:
> 
> |> Pardon me -- I'm a sys admin who doesn't know much of anything about
> |> programming other than how to ruin a perfectly good makefile.  Could
> |> someone please explain the distinction between atomic and non-atomic
> |> system calls from an admin's perspective on system performance issues?
> |> The SunSolve article referred to earlier in this thread was opaque to
> |> me.
> 
> Say you want to perform the following operation:
> 
>         "See if file xyz.lock exists.  If not, create it."
> 
> In general this is made up of 2 steps:
> 
>         1)      See if the file exists
>         2)      If not, create it
> 
> The problem is that on a multiuser system other processes could be running at
> the same time.  And therefore it's possible that another process could sneak
> in between steps 1 and 2 and create the file before this process gets to step
> 2.  Therefore the semantics would be broken.
> 
> Worse - the first process would probably not have an error signalled - instead
> both processes would both get to the end of step 2, notice the file existed,
> and think they had the supposedly-exclusive lock.
> 
> An atomic version, on the other hand, provides a single system call which
> performs both of the steps above *as a single operation*.  I.e. it guarantees
> that nothing else can get in between the two operations and mess things up
> (effectively this is the definition of "atomic").  This even works in
> multi-CPU systems.
> 
> Given that microprocessors really execute a whole sequence of non-atomic
> instructions, people need to simulate atomic high-level operations.  This is
> OK, since in most cases it is possible to make a multi-step operation seem to
> be atomic by wrapping it with:
> 
>         get_lock(...):
>                 step_1();
>                 step_2();
>                 /* etc. ..... */
>         release_lock(...);
> 
> But this does rely on there being at least some low-level atomic operation
> that can be used to implement an atomic get_lock() call.  Especially across
> multiple machines, people often attempt to implement such locks via the file
> system, and this rather relys on a certain set of atomic file operations such
> as rename(), and open(..., O_CREAT|O_EXCL) being available.
> 
> Hugh.

[prev in list] [next in list] [prev in thread] [next in thread]