Re: Is there some implicit locking of device methods?

On Thu, Apr 28, 2011 at 12:14:49AM +0200, Bartosz Fabianowski wrote:
Indeed, I may have mixed up terminology. Sorry about that. What I am
doing (or trying to do) is very simple:

There is a single physical USB device. I have a single device node
representing it. This device can be opened for reading, concurrently,
any number of times. Everyone who open()s the device can read() it at
their own pace. I implemented this by maintaining an individual queue of
incoming data for each open() call. This queue resides in cdevpriv.

So open() instantiates a queue and adds it to the driver's global list
of queues. Whenever a packet arrives from the device, it is placed in
all the queues (I have a linked list of all queues for that purpose).
When the open() is eventually followed by a close(), the cdevpriv
destructor removes the queue from the global list and frees its memory.

In addition to this, I need to start the USB transfer when the first
open() occurs and stop it again when the last close() occurs. I am doing
this by checking the length of the global list. When the list is
zero-length on open(), I start the transfer. When the list i zero-length
in the cdevpriv destructor, I stop the transfer.

I cannot see how else to achieve this behavior (other than device
cloning which I was using before but which is more complicated and
probably more error-prone). If I am doing something wrong and there is a
more correct way to do it, I would love to hear about it.

This is a strange architecture, esp. amusing is the kernel-mode
traffic multiplier. Without knowing the details, and really not wanting
to know it, I could make two suggestions out of thin air:

- use usermode daemon that multiplies traffic for all connected clients;

- or, implement a ring buffer that cyclically stores the received data,
and keep only the current read pointer in the cdevpriv. You need to
handle the overflow case (eq. to the stuck reader) somehow in the
current scheme anyway. Reader may now read from its current read
position in the buffer up to the fill point. If the buffer wrapped
for the reader, it should get some error.

Attachment: pgpyg7X5xa53a.pgp
Description: PGP signature

Relevant Pages

  • Re: RCU+SMR
    ... The single reader just grabbed the entire queue using compare and swap, reversed order making it FIFO and worked off of that util it was empty and then repeated the whole process by grabbing the shared LIFO stack again. ... If you had spare hardware threads, you could have one doing the reverse linking in parallel with the reader thread and improve latency for the reader thread. ...
    (comp.programming.threads)
  • Re: Thread Checking the Queue data in an infinite loop
    ... Yes Reader will acquire the mutex to access the each data element. ... Your pseudo code of Reader and writer has one problem where the reader ... acquires the Lock to drain the whole queue (i have a mutex which has ... all writer threads write to the IOCP and all consumer threads read from the IOCP. ...
    (microsoft.public.vc.mfc)
  • Re: Circular buffer
    ... >If the writer is consistently faster than the reader, ... > its speed with the reader. ... > single element buffer instead of a queue. ...
    (comp.programming)
  • Re: Circular buffer
    ... >If the writer is consistently faster than the reader, ... > its speed with the reader. ... > single element buffer instead of a queue. ...
    (comp.programming)
  • RE: single-reader/ multiple-writers message queuing
    ... The OS message queues support multiple writes and a single reader. ... - The reader creates the message queue. ... you can have writer threads block until ...
    (microsoft.public.windowsce.app.development)