core: merge msg into mbox

[miri64]

From my understanding there is some shared functionality between the asynchronous behavior of core_msg and core_mbox: messages are put into a queue by n threads and gotten out n threads. In case of core_msg n is however one.

On one hand side we might get some code size benefits in merging the two, on the other we would put some more complexity into the asynchronous behavior of core_msg, since it isn't required to handle more than one reception thread.

A good compromise in my opinion would be to provide an new mbox implementation that assumes only one reader and base the old mbox and msg implementation on it. I started something into that direction in this branch. But I

1. did not port msg yet
2. am not sure if this

   RIOT/core/mbox_base.c

   Lines 63 to 66 in 1631d29

   	if (blocking) {
   	_mbox_base_wait(&mbox->writers, irqstate);
   	irqstate = irq_disable();
   	}

   and that

   RIOT/core/mbox_base.c

   Lines 92 to 96 in 1631d29

   	if (next) {
   	thread_t *thread = container_of((clist_node_t*)next, thread_t,
   	rq_entry);
   	_mbox_base_notify(thread, irqstate);
   	}

   is still possible, as both _mbox_base_put() and mbox_base_get() would be called by the wrapper implementations of mbox and msg, both might have their own irqstate stored (and thus it might not properly return to the right IRQ state in both _mbox_base_wait() and _mbox_base_notify().

[kaspar030]

I had an msg implementation that used mbox below. I didn't PR it because plain msg was simply faster. Whatever you come up with, try bench_msg() on real hardware.

[miri64]

@kaspar030 any thoughts on 2.?

[miri64]

Ping @kaspar030?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.