Question

I am looking for advices or pointers on how to design a specific part of a Mac OS X network kernel extension to be as fast and efficient as possible – C language.

Description: I have two sets of TAILQ lists. One for type A structures, the other for type B structures. Mostly, I deal with them separately, thus have a lock_mtx for each one. Sometimes, I need to modify A, then B, then both at the same time. It looks like this :

Function1:
{
Modify List or Struct A
Modify List or Struct B
Modify List or Struct A & B
Modify List or Struct B
Modify List or Struct A
}

Function2:
{
Modify List or Struct B
Modify List or Struct A & B
Modify List or Struct A
Modify List or Struct A & B
}

I am not familiar with the use of locks. So I see only two options: 1. Use a single lock to protect both lists. That would be a waste, since it would prevent function modifying A only to execute while a function modifying B only is executing (and vice versa).

  1. Take both locks successively, and release them. That would give me:

.

   Function1:
    {
    lock A
    Modify List or Struct A
    unlock A

    lock B
    Modify List or Struct B
    unlock B

    lock A
    lock B
    Modify List or Struct A & B
    unlock B
    unlock A

    lock B
    Modify List or Struct B
    unlock B

    lock A
    Modify List or Struct A
    unlock A
    }

I feat this would be quite expensive, taking all those locks. Is there a better way to protect cross-modifications of A and B ?

Thanks for your advices.

Was it helpful?

Solution

Initially, I was looking for design advices in the context of the above-asked question.

Well, it turns out that thought using kernel level mutex seems to be the right call, there are no clear-cut answer. Too much depends on the exact structure of the functions and on the time spent doing side-work that does not require to be carried out in locked context.

In such situations, the best answer, hinted by dario_ramos and pmjordan, would be to profile viable options and make a choice.

Thank you all for your help.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top