About scheduling

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

About scheduling

Pablo Herrero
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!

Reply | Threaded
Open this post in threaded view
|

Re: About scheduling

Stefan Marr-4

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


Reply | Threaded
Open this post in threaded view
|

Re: About scheduling

Lukas Renggli
In reply to this post by Pablo Herrero
    [ ... ] valueUnpreemptively

but read the method comment.

Lukas

On 24 November 2011 19:07, Pablo Herrero <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: About scheduling

Igor Stasenko
In reply to this post by Pablo Herrero
On 24 November 2011 20:07, Pablo Herrero <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: About scheduling

Pablo Herrero
2011/11/24 Igor Stasenko <[hidden email]>:
>>
> 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.

Reply | Threaded
Open this post in threaded view
|

Re: About scheduling

Igor Stasenko
On 25 November 2011 16:25, Pablo Herrero <[hidden email]> wrote:

> 2011/11/24 Igor Stasenko <[hidden email]>:
>>>
>> 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.

Reply | Threaded
Open this post in threaded view
|

Re: About scheduling

Pablo Herrero
2011/11/25 Igor Stasenko <[hidden email]>:

> On 25 November 2011 16:25, Pablo Herrero <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: About scheduling

Igor Stasenko
On 25 November 2011 19:58, Pablo Herrero <[hidden email]> wrote:

> 2011/11/25 Igor Stasenko <[hidden email]>:
>> On 25 November 2011 16:25, Pablo Herrero <[hidden email]> 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.