[9fans] odd rwakeup qunlock behaviour in 9vx

[9fans] odd rwakeup qunlock behaviour in 9vx

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 710 bytes --]

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-Meba86a2cee63818883e31403
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1507 bytes --]

Re: [9fans] odd rwakeup qunlock behaviour in 9vx

[ori]

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

Re: [9fans] odd rwakeup qunlock behaviour in 9vx

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1989 bytes --]

Re: [9fans] odd rwakeup qunlock behaviour in 9vx

[Lucio De Re]

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

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 3836 bytes --]

Some time ago I wrote an email to p9f for registration of a user account in the contrib folder but that mail never got delivered. Otherwise I would regularly place a binare image for x86 for testing the effect of changes I made to the kernel and userland regarding performance.

Regarding code samples : I'm using plan9 compilers as backends for my own C with Objects dialect which gets preprocessed and generates code understood by the plan9 compilers. My fork of plan9 isn't of general interest cause its goal is to provide a small (currently 4,8 MB) graphical terminal which connects to a closed area network server over tcp/ip for education purposes. I avoid using 9p where possible to improve the performance of the system which hasn't the goal to be a network operating system like plan9. I like the "everything is a file" model but implemented it in form of a block oriented memory file system using shared memory segments which leads to a great performance boost cause interprocess communication between processes on a single machine are realized in the form of file exchange without any form of translation to 9p and transfer over bytestreams which is surely necessary for a networking operating system like plan9 but not for an isolated machine which has only a proprietary tcp/ip protocol connection to a well defined server. For kernel files in /dev I wrote wrapper processes which transfer changes into the shared memory file system realm. 

In the first versions I used locks (especially lock and canlock) with polling in slave processes. For the next version I tried to avoid polling by using qlocks rsleep and rwake but while testing under 9vx, qemu and on bare metal the above mentioned problems appeared. When a process using Rendez and QLock structures in a shared memory segment called rwake more than once during its executing cycle first 9vx crashed than qemu crashed in an absurd way and also the bare metal version crashed.

The reasoning behind this thread is only informing others about possible problems I encountered. I don't need a solution I already have a working workaround using simple locks. My code would be of no benefit for other plan9 users or developers but if there is interest for investigating the problem I can write a simplified example which reproduces this behavior. 

P.S. The shared memory is not attached with segattach but provided from rfork/exec which could be one reason behind this problem. rfork copies the parent segments into the list which can be accessed using proc/n/segment and using segments in this way is different from using segments by using segattach in many ways.  Perhaps this is also the reason for the crashes.

On Wednesday, 8 November 2023, at 10:08 PM, ori wrote:
> 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.
I also didn't have problems using qlock rendez without the combination of shared memory and rfork based shared segments.

On Thursday, 9 November 2023, at 4:16 AM, Lucio De Re wrote:
> I am sincerely hoping you intend to publish your efforts that
certainly sound very promising.
I intend shareing at least a binary version of my forked simple version after porting scintilla to my gui system cause right my system consists mainly of a viewer for a simplified markup which is used to present lecture notes, sound and animations (proprietary format).
An editor is my minimal expectation towards myself before making such an image available for discussions on this mailing list. 



------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T7a5bb3cde50a8a9a-Mfe4be6cb472537ea35f1d195
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 4712 bytes --]

Re: [9fans] odd rwakeup qunlock behaviour in 9vx

[Lucio De Re]

On 11/10/23, ibrahim via 9fans <9fans@9fans.net> wrote:
> [ ... ]
>
> The reasoning behind this thread is only informing others about possible
> problems I encountered. I don't need a solution I already have a working
> workaround using simple locks. My code would be of no benefit for other
> plan9 users or developers but if there is interest for investigating the
> problem I can write a simplified example which reproduces this behavior.
>
This is interesting enough to catch my attention, I'm curious in
exactly that way.

Thank you for taking the time to compose your reply, which is
definitely an improvement on the short, insulting exchanges that seem
to pop up in this list most of the time.

Lucio.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T7a5bb3cde50a8a9a-M34f4254c3d0c1808831f5047
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription