views:

76

answers:

2

I'm developing a project and I have to make a wrapper to some hardware functions.

We have to write and read data to and from a non-volatile memory. I have a library with the read and write functions from the seller company. The problem is that these functions should be called with a delay between each call due to hardware characteristics.

So my solution is to start a thread, make a queue and make my own read and write functions. So every time my functions are called, the data will be stored on the queue and then in the loop thread will be actually read or written on the memory. My functions will use a mutex to synchronize the access to the queue. My wrapper is going to be on a dll. The main module will call my dll init function once to start the thread, and then it will call my read/write functions many times from different threads.

My questions is: Is it safe to do this? the original functions are non reentrant. I don't know if this is going to be a problem. Is there a better way to do this?

Any help will be appreciated.

A: 

Adding a mediator in this context is a pretty typical solution so you aren't out in the weeds here. I would say you would need to implement this because the original functions are not reentrant. Assuming, of course, that you own the access to the hardware. (i.e. You are the driver.) If other people can get access to the same piece of hardware, then you're going to have to come up with some higher level contract. Your thread then provides the ordered access to the driver. You'll find that the mediator will also allow you to throttle.

The hard part it seems is knowing when it is okay to make the next call to the device. Does it have some sort of flag to let you know it is ready for reads and writes? Some other questions: How do you plan to communicate state to your clients? Since you are providing an async interface, you'll need to have some sort of error callback registration, etc. Take a look at a normal async driver interface for ideas.

But overall, sounds like a good strategy to start with. As another poster mentioned, more specifics would be nice.

Andrew Mellinger
Thanks for your answer Andrew...I have no flags, I'm just going to wait 100 ms for the next call.And still have no idea on how to tell my clients that the write functions was done successfully.
kepler
Here's a couple of options. 1) When they call the write they give you a callback. You call them back when you are done with the write and they can post another one. 2) When they call write, you give them a receipt that has a "isDone()" or something they can call to see if you are done.I would prefer the first method myself. But be careful when you call them. If you call them on your thread, then they might block your thread. You might want to have yet another thread for those callbacks. Also it sounds like you might want to encourage double buffering.
Andrew Mellinger
A: 

Sorry I forgot something:

-The language to be used is C++

-The main program will call my wrapper dll but also will call other modules (dlls) that are going to call the wrapper dll.

kepler
This should be edited into the question itself (or failing that, post it as a comment under the question), not as an answer
jalf