X hits on this document

PDF document

February 10, 2006 - page 29 / 238

641 views

0 shares

0 downloads

0 comments

29 / 238

2.2. OPENIPMI CONCEPTS

17

presence, whether and MC is active, and entity hot-swap state is dynamic, but the vast majority of informa- tion is not. So, it is recommended that you collect all the static information that you need from an object when it is reported to you.

Many operation require a message to the remote system; the ones that take callbacks. For these operation, functions that directly take the id are available.

Use of the id-base functions is recommended. The entity presence code could be rewritten using this to be:

void c h e c k _ i f _ m y _ e n t i t y _ p r e s e n t ( m y _ d a t a _ t * d a t a { )

int rv;

data->exists = 0; data->present = 0; rv = ipmi_entity_id_is_present(my_entity_id, &data->present); if (rv)

printf("The entity could not be found\n"); else

data->exists = 1;

}

Locking semantics

As mentioned before, OpenIPMI will not delete an object you have a pointer to while in a callback, but in multi-threaded systems it is free to do pretty much anything else to the object, including call callbacks on it. This means, for instance, that you can be iterating over the entities in the system and a new entity can be added, have the entity update callback called on it, and be added to the list. There is no guarantee or order between the adding of entities to the list and the callback. So the new entity might be iterated, it might not, the iteration might be before or after the the callback, etc.

How can you avoid this? You have a few options:

  • Ignore the problem. I strongly recommend that you do not take this option.

  • Single-thread your program. If you don’t need be able to take advantage of multiple CPUs in an SMP system, and you have no need for priorities, single-threading is a good option. With OpenIPMI, you can have a single-threaded application that is non-blocking and can perform very well. Plus, single-threaded programs are easier to debug, easier to understand and maintain, and more reliable.

  • Do your own locking. For instance, you could claim a lock in both the entity iteration and the callback for a new entity. This would prevent the both pieces of code from running at the same time. You are in control of the locks, so you can handle it as appropriate. You have to know what you are doing, but that goes without saying when doing multi-threaded programming.

This is pretty standard in multi-threaded systems. Hardware Platform Interface (HPI), for instance has the same problem. If you have one thread waiting for events from an HPI domain, and another iterating the RDRs, or you have two threads each doing operations on sensors, you have exactly the same situation. You have to protect yourself with locks the same way.

Document info
Document views641
Page views641
Page last viewedThu Dec 08 16:40:04 UTC 2016
Pages238
Paragraphs8090
Words85809

Comments