Mon 20 Apr 2009 12:26:53 PM UTC, comment #3:
This is obviously missing.
Now I understand.
First recall the purpose of a shadow BB.
A shadow BB is an *LOCAL* image of a real BB.
A shadow BB should only accept read-only operation
on its structure (i.e. no publish).
The side effect is that one may ignore locking
on the shadow BB.
tsp_bb_provider uses a shadow blackboard in order
to minimize locking time of the real BB.
Essentially you
bb_lock(bb_real);
bb_shadow_update_data(bb_real,bb_shadow);
bb_unlock(bb_real);
The shadow blackboard existed BEFORE there were different
Blackboard types (SYSV, POSIX, KERNEL etc...),
thus we had the bb::status "BB_STATUS_SHADOW" value which was
checked in both bb_lock and bb_unlock in order
to make them no-op operations in those cases.
Now that we have blackboard "type" I think we should make
SHADOW blackboard a new type of Blackboard and not
an ugly test on the "bb->status".
Thus we could create proper:
shadow_bb_XXXX functions, most of them should return an error
(publish, sem_get, sem_destroy, msgq_xxx, ...)
lock/unlock (should be no-op) the remaining (shmem_xxx)
should be as simple as giving a reference to local memory.
|