File locking & device drivers

Ulf Wiger <>
Tue May 14 16:33:24 CEST 2002


On Tue, 14 May 2002, Leonid Timochouk wrote:

>Hello Erlang users,
>
>I am trying to implement a file locking capability (an interface
>to the "flock" system call) in Erlang. Unfortunately, the "file"
>module does not provide it straight away.
>
>My first approach was to build a linked-in device driver, and it
>works almost fine (it uses "flock" in non-blocking mode in order
>not to block the whole Erlang node). There is a problem,
>however: it communicates with the Erlang code by sending
>messages, and the driver responses come into the same main
>message queue of the calling process. Now, suppose we have a
>process which reads incoming data from its message queue and
>writes them into a file, locking the file each time. Then the
>whole message queue would need to be traversed each time by the
>run-time system when we try to fetch the driver responses, so
>saving messages in a file has QUADRATIC rather than linear
>complexity w.r.t. the length of the incoming queue. This is a
>major inefficiency.

<aside>
  I'm not sure I see the implementations where the number of
  queued responses in that single process would grow so large
  that the quadratic complexity would actually become a problem.
  You'd probably need at least a hundred processes locking files
  simultaneously for this to become noticeable. I assume that the
  interface to your "flock" is synchronous to the caller, so each
  process would only have one outstanding lock request.
  Considering the overhead for talking to the file system in the
  first place, scanning the message queue should not become
  noticeable unless you have a very large number of clients
  (assuming that the file system doesn't add so much more
  overhead that this is still relatively insignificant.)
</aside>

Still, if you use driver_send_term() to send the reply
directly to the client (which can be identified
through driver_caller()). You can also register the driver
instance through the normal register/2 BIF. This way, the caller
doesn't have to know the port ID.

/Uffe
-- 
Ulf Wiger, Senior Specialist,
   / / /   Architecture & Design of Carrier-Class Software
  / / /    Strategic Product & System Management
 / / /     Ericsson Telecom AB, ATM Multiservice Networks





More information about the erlang-questions mailing list