[lwip-devel] [task #7212] Add Mutex concept in sys_arch

[Frédéric Bernon]

Follow-up Comment #5, task #7212 (project lwip):

>That's rather inefficient. You need a task just to process incoming packets,
separate from the tcp/ip task. That's a whole extra thread stack and context
switch overhead. I don't think that's what most developers would do. (or at
least would want to do if they had an alternative). They'd want to pass the
packets directly to the lwip tcpip thread. We must not rely on such a model.
My port does not do it for sure. The old eCos port did, but that was very
wasteful. 

Perhaps it need an explain. In fact, my design choice answers to several
contraints of my platform, and my first release was based on a IT which
directly pass packets, with a SYS_ARCH_PROTECT based on disable interrupts.
But, in my case, interrupts have to be really short to have no impact on the
global performance of the system due to cache management (it's a DSP, and
there is some tasks which have to be less interrupted as possible, and the
network sub system is not the one with the higher priority, disable interrupts
give my stalls delays I have to reduce). That's why in my case, my system got
a better performance with this design than with the one you find better for
eCos port. But, this is another subject of course, and such design choice
depend of the target to my point of view.

>err_t sys_mutex_new...

About these functions, I have try to be coherent with current sys_* ones. The
error checking should done by comparing the sys_mutex_t with a SYS_MUTEX_NULL
for _new, like for sem & mbox. Of course, if we talk to redesign all sys
functions, this is another story (but, to minimize impact on current source
code, you should specify that your sys_mutex_new set to SYS_MUTEX_NULL in case
of error, same for sem & mbox). I think we should have a coherence with all
sys_ when/if we introduce mutex. So, saying my proposition is better with
current sys.h, and, when/if you change the others (mbox & sem), your
proposition will be better...

>Note that I have sys_mutex_lock() returning success/failure. That's because
some OSes can return errors on lock (e.g. if they are broken out of the wait).
Although I'm not sure whether that's something we should worry about or not.
Perhaps we should leave it to the port to just throw its own assertion failure
in that case. Thoughts?

In this case, I suppose the problem should be the same for sys_arch_sem_wait?
But I think that throw an assert failure inside the sys_arch is the right
thing to do in these error cases.



    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/task/?7212>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.nongnu.org/