Smalltalk › Pharo › Pharo Smalltalk Users

About scheduling

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

8 messages Options

Pablo Herrero

About scheduling

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!

Stefan Marr-4

Re: About scheduling

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

Lukas Renggli

Re: About scheduling

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

Igor Stasenko

Re: About scheduling

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.

Pablo Herrero

Re: About scheduling

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.

Igor Stasenko

Re: About scheduling

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.

Pablo Herrero

Re: About scheduling

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.

Igor Stasenko

Re: About scheduling

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.