[vwnc] Any need to protect a paired bytecode push?

It may not be as simple as this.  I consider it quite likely that VisualWorks would never interrupt between two assignment statements.  VisualWorks dynamically compiles the bytecodes into native code.  Since VisualWorks runs under one OS thread, the VM would need to check periodically for task switches.  In the old days (when the bytecodes were interpreted), it was easy to check for interrupts after executing x number of bytecodes, but with native code, I rather doubt that the VM could test for task switches after every bytecode.  It makes more sense to check on message sends and jump bytecodes.  If this is the case, the VM could never interrupt between two sequential assignments.

I haven't verified or checked this, so it's just a theory, but the standard answers may be wrong for this question.

David

Chris Winemiller wrote:

Use a critical section.   Yes, this requires you to use a Semaphore.  But atomicity is your application's requirement so you have little choice.  Have you executed tests proving that a critical section slows down your performance to an unacceptable level?

Chris

Paul Baumann wrote:

I have an object with two inst vars (iVarA and iVarB) that are both updated together. I want to make sure that it would not be possible for another process (sending #getAB) to ever see the old value of an iVarB just after iVarA was changed to a new value but before iVarB had also been set.

 

setA: newValueA andB: newValueB

    iVarA := newValueA.

    iVarB := newValueB.

 

1 <10> push local 0
2 <58> store inst 0; pop
3 <11> push local 1
4 <59> store inst 1; pop
5 <60> push self; return

getAB

    ^Array with: iVarA with: iVarB

 

1 <34> push Array
2 <00> push inst 0
3 <01> push inst 1
4 <F0 4A> send with:with:
6 <65> return

Question 1: Is it possible for another process to get some action in #setA:andB: between the setting of the two inst vars?

 

For years I've assumed the answer is Yes, but all concerns go away if that assumption is incorrect.

 

Question 2: Is it possible for another process to get some action in #getAB between each inst var push?

 

It would be wonderful if the answer is No.

 

Obviously, concurrency issues are what semaphores are made for. I'm looking for something faster than a semaphore for this code. I'm also looking for something faster than #valueUninterruptably and #valueUnpreemptively. A comparision loop is one way to do it, but it would be wonderful if concurrency fears can be dismissed for one or both of these methods.

 

These are a VM implementation kinds of questions. A delayed process that is scheduled to resume at a certain time can preempt the active process.

 

Another way to ask these questions:

    Does the VW VM preempt push operations within a stack frame/context or only between frame/context transitions?

 

 

Paul Baumann 

 

---

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
  

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
  

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

It may not be as simple as this.  I consider it quite likely that VisualWorks would never interrupt between two assignment statements.  VisualWorks dynamically compiles the bytecodes into native code.  Since VisualWorks runs under one OS thread, the VM would need to check periodically for task switches.  In the old days (when the bytecodes were interpreted), it was easy to check for interrupts after executing x number of bytecodes, but with native code, I rather doubt that the VM could test for task switches after every bytecode.  It makes more sense to check on message sends and jump bytecodes.  If this is the case, the VM could never interrupt between two sequential assignments.

I haven't verified or checked this, so it's just a theory, but the standard answers may be wrong for this question.

David

Chris Winemiller wrote:

Use a critical section.   Yes, this requires you to use a Semaphore.  But atomicity is your application's requirement so you have little choice.  Have you executed tests proving that a critical section slows down your performance to an unacceptable level?

Chris

Paul Baumann wrote:

I have an object with two inst vars (iVarA and iVarB) that are both updated together. I want to make sure that it would not be possible for another process (sending #getAB) to ever see the old value of an iVarB just after iVarA was changed to a new value but before iVarB had also been set.

 

setA: newValueA andB: newValueB

    iVarA := newValueA.

    iVarB := newValueB.

 

1 <10> push local 0
2 <58> store inst 0; pop
3 <11> push local 1
4 <59> store inst 1; pop
5 <60> push self; return

getAB

    ^Array with: iVarA with: iVarB

 

1 <34> push Array
2 <00> push inst 0
3 <01> push inst 1
4 <F0 4A> send with:with:
6 <65> return

Question 1: Is it possible for another process to get some action in #setA:andB: between the setting of the two inst vars?

 

For years I've assumed the answer is Yes, but all concerns go away if that assumption is incorrect.

 

Question 2: Is it possible for another process to get some action in #getAB between each inst var push?

 

It would be wonderful if the answer is No.

 

Obviously, concurrency issues are what semaphores are made for. I'm looking for something faster than a semaphore for this code. I'm also looking for something faster than #valueUninterruptably and #valueUnpreemptively. A comparision loop is one way to do it, but it would be wonderful if concurrency fears can be dismissed for one or both of these methods.

 

These are a VM implementation kinds of questions. A delayed process that is scheduled to resume at a certain time can preempt the active process.

 

Another way to ask these questions:

    Does the VW VM preempt push operations within a stack frame/context or only between frame/context transitions?

 

 

Paul Baumann