Re: [9fans] odd rwakeup qunlock behaviour in 9vx
On 11/9/23, ibrahim via 9fans <9fans@9fans.net> wrote: > > If there is interest for reproducing the exact circumstances I can write a > small example app which involves different processes accessing the same > shared memory segments which are inherited by the rfork methods. > I assume that such an example, in this context, would be instructive, if not immediately, certainly in the more distant future. I am sincerely hoping you intend to publish your efforts that certainly sound very promising. Lucio. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T7a5bb3cde50a8a9a-Mcab3b424e9df06fcb544af90 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] odd rwakeup qunlock behaviour in 9vx
Thanks for your reply. This behavior only appeared while using shared memory in form of segments. I already solved this problem by exchanging qlock, qunlock by lock (canlock). I also didn't have any problems while using other forms of memory constellations but while using shared memory segments this problem surfaced. I need this for my vgafb implementation which makes use of shared physical and normal shared memory segments. After testing on bare metal I also found out that qlock, qunlock, rsleep, rwake ... caused kernel crashes on bare metal while usual locks work without any problems. On 9vx I had to simulate vgafb with a implementation which provided my framebuffer with a shared segment to transfer changes to devdraw this made development easier but the moment I had concurrent access my software crashed. Debugging made clear the source of the crash was the described call combination while using shared memory segments. If there is interest for reproducing the exact circumstances I can write a small example app which involves different processes accessing the same shared memory segments which are inherited by the rfork methods. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T7a5bb3cde50a8a9a-M62c35c1979d8c1e3f89621f0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] iwp9 paper submission ?
27.10.2023 18:40:51 o...@eigenstate.org: > Short summary -- we're working on it. It's likely to be at a different > location than we had initially announced. We're waiting to confirm > before we put out the call for papers and specific dates. Are there any news on that? If there are bigger issues with the location, I could ask my local university, just let me know. > It will be happening. That's definitely good to hear. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2cf2f3b242100bba-M95a738754da98b1b2a6f4072 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] odd rwakeup qunlock behaviour in 9vx
A complete snippet to reproduce this may be useful. That
said, I have code that uses qlock and rendez heavily with
no sleeps, and have not had any issues on 9front.
Quoth ibrahim via 9fans <9fans@9fans.net>:
> I have a function chan_send in which :
> chan_send (...) {
> qlock()
> rwakeup(...)
> qunlock()
> }
>
> If two such chan_send functions are called without a "task-switch" 9vx
> crashes. A work around for this problem is to place a sleep(0) after qunlock
> to enforce a task-switch
>
> chan_send(...) {
> qlock()
> rwakeup(...)
> qunlock()
> sleep(0)
> }
>
> This behaviour isn't documented anywhere. I'll test it next on bare metal
> with a real kernel to find out if this is only a 9vx problem.
>
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T7a5bb3cde50a8a9a-M861c10f8be4b323658622f9a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
