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


Groups > comp.os.linux.misc > #8125

There are or are not shared resources in this device driver example

Newsgroups comp.os.linux.misc
Date 2013-05-13 03:49 -0700
Message-ID <c942acd8-e7e9-44c5-ac5b-73b29eebc050@googlegroups.com> (permalink)
Subject There are or are not shared resources in this device driver example
From fl <rxjwg98@gmail.com>

Show all headers | View raw


Hi,

I read Linux Device Drivers, 3rd edition. I do not understand an example on locking mechanism in Chapter 5. On page 107, it first gave the memory allocation to show the potential racing:

////////////////////////////
Let us take a quick look at a fragment of the scull memory management code. Deep
down inside the write logic, scull must decide whether the memory it requires has
been allocated yet or not. One piece of the code that handles this task is:

if (!dptr->data[s_pos]) {
  dptr->data[s_pos] = kmalloc(quantum, GFP_KERNEL);
  if (!dptr->data[s_pos])
    goto out;
}
.......................

On page 112, it implemented separated semaphore for each virtual device driver.


//////////////////////////
The semaphore mechanism gives scull a tool that can be used to avoid race conditions while accessing the scull_dev data structure. But it is up to us to use that tool correctly. The keys to proper use of locking primitives are to specify exactly which resources are to be protected and to make sure that every access to those resources uses the proper locking. In our example driver, everything of interest is contained within the scull_dev structure, so that is the logical scope for our locking regime.

Let’s look again at that structure:

struct scull_dev {
  struct scull_qset *data; /* Pointer to first quantum set */
  int quantum; /* the current quantum size */
  int qset; /* the current array size */
  unsigned long size; /* amount of data stored here */
  unsigned int access_key; /* used by sculluid and scullpriv */
  struct semaphore sem; /* mutual exclusion semaphore */
  struct cdev cdev; /* Char device structure */
};

Toward the bottom of the structure is a member called sem which is, of course, our semaphore. We have chosen to use a separate semaphore for each virtual scull
device. It would have been equally correct to use a single, global semaphore. The various scull devices share no resources in common, however, and there is no reason to make one process wait while another process is working with a different scull device. Using a separate semaphore for each device allows operations on different devices to proceed in parallel and, therefore, improves performance.
...........................

I am puzzled about the separate semaphore. I think semaphore is useful only for shared resources. Only different device drivers share one semaphore can protect the underlying resources. In the above example, where is the racing for the memory allocation operation concurrently by more device drivers?


Thanks in advance


Back to comp.os.linux.misc | Previous | NextNext in thread | Find similar


Thread

There are or are not shared resources in this device driver example fl <rxjwg98@gmail.com> - 2013-05-13 03:49 -0700
  Re: There are or are not shared resources in this device driver example fl <rxjwg98@gmail.com> - 2013-05-13 04:04 -0700
    Re: There are or are not shared resources in this device driver example Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2013-05-14 22:12 -0400
  Re: There are or are not shared resources in this device driver example fl <rxjwg98@gmail.com> - 2013-05-13 05:09 -0700

csiph-web