bugTransport Sample Protocol - Bugs: bug #26250, Deadlock in BlackBoard

 
 

bug #26250: Deadlock in BlackBoard

Submitter:  MARTINSONS <martinsons>
Submitted:  Mon 20 Apr 2009 09:56:55 AM UTC
   
 
Category:  Blackboard Severity:  3 - Normal
Status:  In Progress Privacy:  Public
Assigned to:  None Open/Closed:  Open
Release:  * 0.8.3-rc1 Fixed Release:  * 0.8.4
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 20 Apr 2009 07:46:02 PM UTC, comment #6: 

I've just tested your patch.
It's working.
Thank you for this.

As noted in the patch comment.
I would rather solve the problem in another way
since the patch only fix the problem for SysV BB type.

I put the bug "In Progress" but left it "unassigned"
because I have no time to work on it now.

Eric NOULARD <erk>
Group administrator
Mon 20 Apr 2009 01:43:17 PM UTC, comment #5: 

Ok I posted a diff , patch #6812

 MARTINSONS <martinsons>
Mon 20 Apr 2009 12:42:33 PM UTC, comment #4: 

Regarding locking scheme between
bb_simu
and
tsp_bb_provider

bb_simu is locking the real BB when it modifies
the values stored in the BB.

This is not mandatory it a "bb_simu" design choice.
On its side tsp_bb_provider is locking the real BB
when calling bb_shadow_update_data, normally this way
the tsp_bb_provider cannot send "unconsistent" BB data.

Most BB user don't care about their BB consistency thus
their own "bb_simu" like applications do not bb_lock.

I think that's why current did not face the bug :-)
The tsp_bb_provider is able to bb_lock multiple time
because the SysV lock may be re-entrant for the same process
(to be confirmed, it's just a guess).

In any case this is a bug that MUST be fixed.
I have no time to patch now,

Frederic (M.) would you be wanting to propose a patch for that?
I'll may be able to review it.

Eric NOULARD <erk>
Group administrator
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.



Eric NOULARD <erk>
Group administrator
Mon 20 Apr 2009 11:18:50 AM UTC, comment #2: 

Excuse my lack of details...

So the semaphore (the one belongs to the blackboard) isn't released by the tsp_bb_provider.The code lines are in bb_core_sysv.c (and bb_core_posix too), in sysv_bb_unlock (before release semaphore):

/* shadow do not honor locking
* they have neither semaphore nor msgqueue attached
*/
    
if (BB_STATUS_SHADOW == bb->status) {
return BB_OK;
}

These lines are not present in sysv_bb_lock.I don't know how the bb_provider works but I think there is a lock operation made on the shadowed bb (by the provider) and a lock made by bb_simu.

But i'm just guessing...

 MARTINSONS <martinsons>
Mon 20 Apr 2009 10:33:32 AM UTC, comment #1: 

Released by who? bb_simu ? tsp_bb_provider?

Which "semaphore" are you talking about?
Do you see any bb_lock with no corresponding bb_unlock?

Could you point us to the suspected source code lines?

 Eric NOULARD <erk>
Group administrator
Mon 20 Apr 2009 09:56:55 AM UTC, original submission:  

(following the thread http://www.mail-archive.com/tsp-devel@nongnu.org/msg01222.html)

A deadlock appears with bb_simu+tsp_bb_provider+ "a consumer".The semaphore is not released when the BB is shadowed, while this semaphore is taken whatever type of BB (shadow or not).

We must not take the semaphore when the BB is shadowed.Is this the good behaviour ? What do you think ?

 MARTINSONS <martinsons>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by erk (Posted a comment)
  • -email is unavailable- added by martinsons (Submitted the item)

    •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-04-20 erk StatusNone In Progress

    Back to the top

    Copyright © 2024 Free Software Foundation, Inc.
    Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
    The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
    Page source code

    Powered by Savane 3.14-f13d.
    Corresponding source code