How to design non blocking device drivers?

Hi all, I would like to understand how to design drivers in such a way that its non blocking?

To be more specific,If suppose I have an EEPROM device and two tasks are trying to write some data to the EEPROM device,generally what happens is,we will have a semaphore inside driver so that till one task completes using the device,the other task will be pending to complete the writing.What would be the way to design the driver in such a way that the second task mentioned above does not go into blocking,but still completes writing to the EEPROM.

Sorry if this query looks naive,I am trying to think on alternatives for one our product.Application is a thirdparty application which needs this requirement.

Looking farward for your thoughts and advanced thanks for the same,

Regards, s.subbarayan

Reply to
Loading thread data ...

Simple solution:

Create a cache for EEPROM in RAM. So the tasks will be modifying and reading that cache (protected by semaphore, of course). This is going to be blocking but only for the short time. Once in a while the EEPROM driver flushes the dirty lines of cache into EEPROM.

Good solution:

Implement the EEPROM driver as the server and the communication to it as the incoming and outgoing transactions.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

State machine.

Reply to
Jim Stewart

That would be the impossible way. You have only one EEPROM, and one EEPROM can only do one write job at a time. So task2 cannot write to the EEPROM while task1 is still doing so. That leaves three possibilities:

1) fail: refuse the write job and return an error condition 2) block: wait for the other task, write, then finish successfully 3) cache: store the write's data and report success, although it hasn't actually been written to EEPROM yet

One can also mix these, e.g. block for a while, but fail if it takes too long. But your requirement to complete writing excludes 3) and 1), and you explicitly excluded 2), which leaves you with no way to do the job.

Reply to
Hans-Bernhard Bröker

You can also send your write requests through a queue to a task whose job it is to do the actual writing.

There are many ways of signalling the end of the writing through events or another queue.

The posting task can mark the operation as 'in wait' until it receives the notification. It can wait upon it or test it regularly. All that is well known and is called asynchronous operations.

Reply to

vers in such a way

You dont do it that way, you have 1 driver that writes to the eeprom. All tasks write to the driver only it writes to the eeprom.

Reply to

... which is just an implementation of case 3).

He said he wanted the data written _to the EEPROM_ without blocking. None of your proposals assures that.

Reply to
Hans-Bernhard Bröker

The other (minor?) issue is that you cannot read from the EEPROM until the write is finished, whether it is in a state machine or queued. The only apparently viable solution is to mirror the EEPROM in RAM and have a background task that slowly updates the EEPROM. Even caching part of the EEPROM will not work because the entire EEPROM would be unavailable.

Reply to

if you absolutely need the drivers to be non blocking then split the eeprom writes to byte by byte, that is write only one byte at a time. if two tasks need to write 20 and 30 bytes respectively and are initiated simultaneously, you can interleave byte writes between task A and task B. But that ofcourse would be a very inefficient way of writing to an EEPROM since you need to change the address every time (assuming it is serial EEPROM). Even if it is a parallel eeprom there will be overheads due to task switching. You can finish the job quicker if you write all data from a task in one go. Non Blocking drivers are useful where the hardware supports it such as a Hard disk drive with native command queuing(NCQ) or a bus like the PCIe where the device requires certain time to complete a read/write task and supports queuing of commands from different tasks so that the performance can be improved.


Reply to

While I agree that such a response is a reasonable caution for the solutions provided, it is a little much to take a vague user need statement that is not achievable if interpreted exactly and then reject solutions that are working toward the likely intent of the user need.

The correct response here is really to ask for further clarification on what the actual desired end state actually is and use these various solutions to discuss in which ways they address the aspects of the needs statement and in which ways they may fail short. The numbered list at the top of this message actually does a pretty good job of categorizing likely outcomes all possible solutions.

The most logical interpretation of the user need statement implies he is looking for solutions that fall into some form of category 3. While it is dangerous to assume that the most logical interpretation of a conflicting user need statement is what they really want, it is certainly not a bad starting place for discussion.

Reply to
Jeffrey Creem

The EEPROM is, itself, blocking (you can't initiate a write while it's writing), so a driver for it is either going to reflect that, or you're going to have to mirror the EEPROM and schedule writes.

So your choice is blocking, or a fairly complex shadowing scheme.

Tim Wescott
Control systems and communications consulting
 Click to see the full signature
Reply to
Tim Wescott

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.