[EMAIL PROTECTED] wrote on 03/10/2008 07:31:23 AM:
> As we are planning to design a new shelf based system we have also
> decided to implement OpenHPi architecture for the hardware
> management. As the hardware layer will be proprietary we started
> work on a new Plugin that will also act as a hw. Management Server.
> In order to this we already implemented a separate thread that
> starts in the oh_open() function.
> My question is how thread safe are the functions that can be called
> from a plugin and where do we need to call them.
> For instance let us assume that we have discovered all current
> resources an waiting in our proprietary thread for any new events.
> And now here it comes. A new Front board was inserted into the system.
> We now have to call some functions like oh_add_resource, oh_add_rdr,
> etc to add the new resource and data to the rptcache. Can this
> functions be safely called in my new thread or must they be included
> in any of the abi interface functions.
The utility library (libopenhpiutils.so) contains all of the RPT (e.g.
oh_add_resource), entity path, and more, functions. You can use them from
within your threads, but they are not thread-safe. That is, if you are
using oh_add_resource from more than one thread on the same RPTable
object, you need to take appropiate measures.
> The same questions goes for events. Can we call oh_evt_queue_push
> from our separate Thread or must it again be called from one of the
> abi interface functions?
oh_evt_queue_push() can be called from within your threads, too. Also,
oh_evt_queue_push() is thread-safe, so you can call it from multiple
threads without worrying about race conditions.
> Well, in case that the above answers all suggest that we can
> add/remove/synchronize most of our local stuff with the OpenHPI
> infrastructure inside our local Threads, do we actually need to
> perform any work in next abi functions; oh_get_event,
oh_discover_resources?
You don't have to perform any work within oh_get_event if you already have
a thread that will detect hardware events and publish them with
oh_evt_queue_push. This is for plugins that don't have such thread.
If you are already performing initial discovery within oh_open() and are
keeping the resource tree model updated with additions/removals/changes
with other threads, you don't have to do anything within
oh_discover_resources. This is a convenience for plugins that need to be
"reminded" to rescan their resources for changes/additions/removals.
However, I recommend doing your initial discovery within
oh_discover_resources. This function is called periodically, but you can
set it to run one time by setting a static variable flag. OpenHPI will
call discovery on the plugins at startup. In the case of hardware that
takes a long time to discover, this allows for discovery to run in
parallel with OpenHPI's initialization.
--Renier
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
