[Barrelfish-users] Assertion fired when calling "nameserver_register" function

[M Brown]

Mothy,

   Thanks for the detailed explanation. For our example, I can have two threads within one core needing to setup communication. Using your binding protocol, one thread will register a connection name and the other will do a blocking lookup until that name is registered. Since I'm using a single lock per core, if the blocking call executes first it will hold the lock while it is waiting and when the register thread tries to acquire the lock it will also wait causing a deadlock (the name will never be registered).





>>Dear Mark,

>>

>>You're right that a multithreaded environment is the common case.  With Barrelfish, the interface to remote servers >>started as a pure message-passing one, with RPC semantics being added later.  An early decision was to avoid adding >>thread safety to a particular message-passing channel for efficiency reasons; for many use-cases (including >>multithreaded ones) this makes sense.  In the case of the nameserver, it's not ideal.

>>

>>For some of our remote services (such as the memory server), all the RPC calls are wrapped inside a client-side >>library, where we can hide the

>>locking from the user.   In the case of the nameserver, we don't, but

>>clearly we should...

>>

>>One alternative implementation (which we don't have right now) would be to allow lots of outstanding RPCs over a >>single channel, and then dynamically match replies to waiting threads when they arrive.  This would require an >>additional level of accounting not provided by current Barrelfish waitsets (which, like Unix file descriptor sets, >>allow you wait on channels but not specific messages), but for RPC-style interactions might be a better model.

>>

>>That said, I'm still not sure why you could not use a blocking call to

>>the nameserver.   If the nameserver channel binding is protected by a

>>client-side lock, you would only see deadlock if you needed to receive (and reply to) an asynchronous message from the >>nameserver before it would return, but I'm not sure I understand your use case in sufficient detail.

>>

>>  -- Mothy
>>

Thanks,
Mark Brown
Huawei Technologies Inc.
5340 Legacy Dr., Suite 175
Plano, TX 75024
Tel: 469-277-5700 x5870

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.inf.ethz.ch/pipermail/barrelfish-users/attachments/20140219/9b1e86eb/attachment.html