[Olsr-dev] Planned efforts on plugins
Sun Feb 7 14:12:32 CET 2010
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the Olsr-dev