Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.misc > #8128
| Newsgroups | comp.os.linux.misc |
|---|---|
| Date | 2013-05-13 05:09 -0700 |
| References | <c942acd8-e7e9-44c5-ac5b-73b29eebc050@googlegroups.com> |
| Message-ID | <2fdccdf1-7da0-4be0-b7e0-033101bd6929@googlegroups.com> (permalink) |
| Subject | Re: There are or are not shared resources in this device driver example |
| From | fl <rxjwg98@gmail.com> |
On Monday, May 13, 2013 6:49:10 AM UTC-4, fl wrote:
> 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
Hi,
My questions are mainly at the last paragraph. Please correct me or explain it to me if you could.
How can "Using a separate semaphore for each device " to protect shared resources? Specifically, it first gave an example on memory allocation function kmalloc(). I do not understand whether there is connection between these device drivers if they have separate semaphores. Even though the author may mean to use semaphore in the kmalloc(), I don't understand how to implement the separate semaphores.
I may have misunderstand on device and process. The chapter mentions:
'The various scull devices', 'process A', 'process B' etc. Could you help me on last paragraph?
Thanks.
//////////////
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.
Back to comp.os.linux.misc | Previous | Next — Previous in thread | Find similar
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