Hi! Is there any mean to tell the Pharo VM to not switch to any other thread ultil you can tell is safe to do so? Thx in advance!
On 24 Nov 2011, at 19:07, Pablo Herrero wrote:
Hi!
Is there any mean to tell the Pharo VM to not switch to any other thread ultil you can tell is safe to do so?
The VM does only preempt you when another higher prior process becomes runnable. There are a couple of things in the block class, like fork uninterruptible or so. You might want to use those. But you can also just raise your priority to the maximum manually. The relevant global for that is Processor. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
[ ... ] valueUnpreemptively but read the method comment. Lukas On 24 November 2011 19:07, Pablo Herrero <pablodherrero@gmail.com> wrote:
Hi!
Is there any mean to tell the Pharo VM to not switch to any other thread ultil you can tell is safe to do so?
Thx in advance!
-- Lukas Renggli www.lukas-renggli.ch
On 24 November 2011 20:07, Pablo Herrero <pablodherrero@gmail.com> wrote:
Hi!
Is there any mean to tell the Pharo VM to not switch to any other thread ultil you can tell is safe to do so?
Thx in advance!
i would discourage using such things. can you tell , why you need it? -- Best regards, Igor Stasenko.
2011/11/24 Igor Stasenko <siguctua@gmail.com>:
i would discourage using such things.
can you tell , why you need it?
We're developing a STM library, we need to make sure when a proccess is commiting a transacction, nobody else is using the same objects which are been updated.
On 25 November 2011 16:25, Pablo Herrero <pablodherrero@gmail.com> wrote:
2011/11/24 Igor Stasenko <siguctua@gmail.com>:
i would discourage using such things.
can you tell , why you need it?
We're developing a STM library, we need to make sure when a proccess is commiting a transacction, nobody else is using the same objects which are been updated.
Usually for this you just use critical sections. sema := Semaphore forMutualExclusion. process1: sema critical: [ here you modify your data ] process2: sema critical: [ here you commit your data ] so, why this is not appropriate for your model? -- Best regards, Igor Stasenko.
2011/11/25 Igor Stasenko <siguctua@gmail.com>:
On 25 November 2011 16:25, Pablo Herrero <pablodherrero@gmail.com> wrote: Usually for this you just use critical sections.
sema := Semaphore forMutualExclusion.
process1:
sema critical: [ Â here you modify your data ]
process2:
sema critical: [ Â here you commit your data ]
so, why this is not appropriate for your model?
The thing here is that some processes may not be aware there's a transaction running in the background, and could be reading or modifying objects which are involved in some transaction. So it wouldn't be possible for them to anticipate which objects should be accessed inside a lock.
On 25 November 2011 19:58, Pablo Herrero <pablodherrero@gmail.com> wrote:
2011/11/25 Igor Stasenko <siguctua@gmail.com>:
On 25 November 2011 16:25, Pablo Herrero <pablodherrero@gmail.com> wrote: Usually for this you just use critical sections.
sema := Semaphore forMutualExclusion.
process1:
sema critical: [ Â here you modify your data ]
process2:
sema critical: [ Â here you commit your data ]
so, why this is not appropriate for your model?
The thing here is that some processes may not be aware there's a transaction running in the background, and could be reading or modifying objects which are involved in some transaction. So it wouldn't be possible for them to anticipate which objects should be accessed inside a lock.
In this case, all such objects should be wrapped by proxies, then at attempt to access them you entering critical section. Of course this may make things running slower :) To make sure that nothing can interrupt given process, you should run it at highest possible proirity. But then you will rely on scheduling semantics currently employed in system. In case if we change scheduler to allow running processes in parallel or to allow all active processes to progress a bit in given quanta of time, this approach won't work. -- Best regards, Igor Stasenko.
participants (4)
-
Igor Stasenko -
Lukas Renggli -
Pablo Herrero -
Stefan Marr