[Olsr-dev] Planned efforts on plugins

[Henning Rogge]

Am Sonntag 07 Februar 2010 13:59:11 schrieb Erik:
> > An alternative to a scheduler backport would be that the BMF
> > copies the necessary "nexthop" table for each target, so the
> > BMF-thread does not need to look up in the central OLSR core
> > structures. This way the waiting time for both threads could
> > be minimized (just use an atomic switch between two lists of
> > "next hop for originator" databases in the BMF).
> >
> > Henning Rogge
> 
> That is not such a good idea. Making a copy of a table needs, of course, to
> be done in a thread-safe manner. And that would require.... again a mutex.
I know, but the mutex is no sollution at this place.

> Having the OLSR-thread to do the copying is no advantage, because then
>  again the BMF-thread must be blocked from reading while the OLSR-thread is
>  writing into the copy of the table (and vice versa: the OLSR-thread must
>  be blocked from writing while the BMF-thread is reading).
The good thing would be that you can freely handle BMF packages and only need 
to block the thread for the atomic switch between two copies of the 
neighbor/MRP-set. That's a lot better than completely block the BMF or the 
OLSR tread. There is no real multithreading at the moment with the BMF because 
of the mutex.
 
> Whenever there are multiple threads, there will be mutexes. Getting rid of
> the mutex require we use a single-threaded model. This would be possible if
> plug-ins (like BMF) can register for socket events.
You can do this in 0.5.6... unfortunately in a "semi-polling" way because 
OLSRd waits (with nanosleep) a polling interval if no packages are incoming.

> Preferrable in a
> non-polling way, otherwise the performance is severely degraded.
We are thinking about copying the scheduler from the master branch.

Henning
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20100207/033d388c/attachment.sig>