X hits on this document

PDF document

February 10, 2006 - page 24 / 238





24 / 238



  • It’s much easier to detect and manage overload situations in an event driven system. Event-driven systems have event queues of things waiting to be processed. You can put things in the queue and watch the queue length. If the queue length gets too big, you are in overload, and can intelligently decide which events you want to throw away, based on priority, time to live, or some other criteria.

In general, a threaded system is easier to conceptually understand until you understand event-driven methods. An event-driven system is almost always easier to correctly implement.

Note that event-driven systems don’t preclude the use of threads. Threads may be vastly overused, but they are important. You could, for example, allocate one event loop thead per CPU to help scale your system. You need to use threads to manage priorities. Some inputs may be more important than others, so you may have an event loop for each priority and feed them that way. You have a thread per CPU, and/or a thread per priority, but you don’t need a thread per operation.

This is often called “state-machine programming” since most control systems are state-machine based, and this is a natural way to implement a state machine. The op_data holds the state of the state machine, each input gets op_data, looks at the current state, and decides what to do next.

The OpenIPMI library is completely event-driven. It has no internal blocking operations, and it expects that anything it calls will not block. IPMI messaging and operating system primitives are provided through external plug-in pieces.

If a library function that takes a callback does not return an error, the callback is guaranteed to be called, even if the object the call is associated with goes away. If it goes away, a NULL may be passed in as the object to the callback, but the cb_data will still be valid.





The OS handler provides services for the OpenIPMI library. OpenIPMI needs some things from the operating system that are not standardized by the C language. The os-handler include file is shown in Appendix L.

OS Handler Services The classes of services required by OpenIPMI are:

Input Callbacks The OpenIPMI code uses the “file descriptor” concept of *nix, input devices are num- bered. This is not used internally in the library, but it is used by the messaging interfaces, so the messaging interfaces and OS handler may implement their own conventions for these numbers. This provides a way for OpenIPMI to register to receive input from devices.

Timers OpenIPMI times everthing (as it should), thus it needs timers.

Locks OpenIPMI does not require locks, you may leave the operations NULL and they won’t be used. However, if you are doing multi-threaded operations, you should almost certainly provide locks. The locks do not need to be recursive (they used to, but this has changed in OpenIPMI 1.4). Read/write locks are no longer required.

Condition Variables These are condition variables like the ones specified in POSIX threads. Although OpenIPMI does not use condition variables (since it never waits for anything) it may be convenient for other things to have them. OpenIPMI does not use them, and if nothing in your system needs them, they need not be provided.

Document info
Document views1064
Page views1064
Page last viewedFri Jan 20 22:49:47 UTC 2017