#valueNoContextSwitch no different from #value?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

#valueNoContextSwitch no different from #value?

Jaromir Matas
Hi, I tried to test how #valueNoContextSwitch behavior differs from #value. I
created a victim process p and an intruder process q trying to attack where
the difference between #valueNoContextSwitch and #value should lie: between
the #value send and the first context switching point inside the block, i.e.
between points (A) and (B) here:

process p (victim):

   [ x := nil. "(A)" [x "(B)" ifNotNil: ["report intrusion"]] value ]
"repeat many times"

process q (intruder, higher priority)

   [x := 1. "wait a bit"] "repeat"

The #value send is a context switching point too but it's the only one
between A and B in case of #valueNoContextSwitch. So if there were more
switching points inside #value we should see a difference. Unfortunately, I
couldn't see any difference and would really appreaciate your advice where I
am wrong. Here's the whole testing set (outer fork for shielding from UI):

[
| p q x val sema log cycle attempts |
x := val := nil. attempts := 0. cycle := 0. sema := Semaphore new. log := {}
writeStream.
p := [sema wait.
        [x := nil. [val := x. val ifNotNil: [log nextPut: cycle]]
valueNoContextSwitch.
        cycle := cycle + 1. cycle < 100000000] whileTrue.
        Transcript cr; show: 'intrusions: ', log contents size] forkAt: 42.
q := [sema signal.
        [x := 1. attempts := attempts + 1.
        3 milliSeconds wait.
        p isTerminated] whileFalse.
        Transcript show: ' out of ', attempts, ' attempts in ', cycle, ' cycles']
forkAt: 43.
] forkAt: 41

The results in both cases are almost identical:

value:
intrusions: 178 out of 331 attempts in 100000000 cycles
intrusions: 189 out of 324 attempts in 100000000 cycles

valueNoContextSwitch:
intrusions: 194 out of 338 attempts in 100000000 cycles
intrusions: 191 out of 328 attempts in 100000000 cycles


As a side-effect I verified a faulty behavior of #valueUnpreemptively I
reported here:
http://forum.world.st/The-Inbox-Kernel-jar-1368-mcz-tp5126894p5126897.html
<http://forum.world.st/The-Inbox-Kernel-jar-1368-mcz-tp5126894p5126897.html>  

#valueUnpreemptively returns e.g. the following:

intrusions: 0 out of 2 attempts in 100000000 cycles
intrusions: 3 out of 6 attempts in 100000000 cycles

This shows the process p runs at priority 80 even after #valueUnpreemptively
ended and p returned to its previous lower than q priority. As a result q
almost never gets a chance to execute even if it has a higher priority than
p most of the time.

In addition, when I tried to apply the fix I suggested in
http://forum.world.st/The-Inbox-Kernel-jar-1368-mcz-tp5126894p5126897.html
<http://forum.world.st/The-Inbox-Kernel-jar-1368-mcz-tp5126894p5126897.html>
, the performance deteriorated so badly that I'm going to recall my
suggestion (the only reasonable solution to fix the priority issue is a new
primitive).


Any suggestion regarding #valueNoContextSwitch test and where my design is
wrong would be greatly appreciated.
Thanks,




-----
^[^ Jaromir
--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html

^[^ Jaromir
Reply | Threaded
Open this post in threaded view
|

Re: #valueNoContextSwitch no different from #value?

marcel.taeumel
Hi Jaromir.

Wow! That's a thorough experiment. :-) Maybe also add your current conclusions to that other thread: http://forum.world.st/The-Inbox-Kernel-jar-1368-mcz-tp5126894p5126897.html

Best,
Marcel

Am 05.03.2021 09:56:35 schrieb Jaromir Matas <[hidden email]>:

Hi, I tried to test how #valueNoContextSwitch behavior differs from #value. I
created a victim process p and an intruder process q trying to attack where
the difference between #valueNoContextSwitch and #value should lie: between
the #value send and the first context switching point inside the block, i.e.
between points (A) and (B) here:

process p (victim):

[ x := nil. "(A)" [x "(B)" ifNotNil: ["report intrusion"]] value ]
"repeat many times"

process q (intruder, higher priority)

[x := 1. "wait a bit"] "repeat"

The #value send is a context switching point too but it's the only one
between A and B in case of #valueNoContextSwitch. So if there were more
switching points inside #value we should see a difference. Unfortunately, I
couldn't see any difference and would really appreaciate your advice where I
am wrong. Here's the whole testing set (outer fork for shielding from UI):

[
| p q x val sema log cycle attempts |
x := val := nil. attempts := 0. cycle := 0. sema := Semaphore new. log := {}
writeStream.
p := [sema wait.
[x := nil. [val := x. val ifNotNil: [log nextPut: cycle]]
valueNoContextSwitch.
cycle := cycle + 1. cycle < 100000000] whileTrue.
Transcript cr; show: 'intrusions: ', log contents size] forkAt: 42.
q := [sema signal.
[x := 1. attempts := attempts + 1.
3 milliSeconds wait.
p isTerminated] whileFalse.
Transcript show: ' out of ', attempts, ' attempts in ', cycle, ' cycles']
forkAt: 43.
] forkAt: 41

The results in both cases are almost identical:

value:
intrusions: 178 out of 331 attempts in 100000000 cycles
intrusions: 189 out of 324 attempts in 100000000 cycles

valueNoContextSwitch:
intrusions: 194 out of 338 attempts in 100000000 cycles
intrusions: 191 out of 328 attempts in 100000000 cycles


As a side-effect I verified a faulty behavior of #valueUnpreemptively I
reported here:
http://forum.world.st/The-Inbox-Kernel-jar-1368-mcz-tp5126894p5126897.html


#valueUnpreemptively returns e.g. the following:

intrusions: 0 out of 2 attempts in 100000000 cycles
intrusions: 3 out of 6 attempts in 100000000 cycles

This shows the process p runs at priority 80 even after #valueUnpreemptively
ended and p returned to its previous lower than q priority. As a result q
almost never gets a chance to execute even if it has a higher priority than
p most of the time.

In addition, when I tried to apply the fix I suggested in
http://forum.world.st/The-Inbox-Kernel-jar-1368-mcz-tp5126894p5126897.html

, the performance deteriorated so badly that I'm going to recall my
suggestion (the only reasonable solution to fix the priority issue is a new
primitive).


Any suggestion regarding #valueNoContextSwitch test and where my design is
wrong would be greatly appreciated.
Thanks,




-----
^[^ Jaromir
--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html



Reply | Threaded
Open this post in threaded view
|

Re: #valueNoContextSwitch no different from #value?

Jaromir Matas
I'm just working on it :D
Thanks,



-----
^[^ Jaromir
--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html

^[^ Jaromir