Inconsistency in changing the state of task ??

Inconsistency in changing the state of task ??

[prash_t]

Hi,
     while browsing through fs/select.c file of 2.4.19, I came across two 
DIFFERENT ways of changing the state of the current task in do_select(): 

            set_current_state = TASK_INTERRUPTIBLE;
     AND    current->state = TASK_RUNNING; 

I am curious to know if the second line of code doesn't cause any problem in 
SMP systems.  I also see the same situation in do_poll(). 

Please cc to my id since I am not subscribed to the mailing list. 

Thanks
Prashanth

Re: Inconsistency in changing the state of task ??

[Robert Love]

On Tue, 2003-03-04 at 03:36, prash_t@softhome.net wrote:

>      while browsing through fs/select.c file of 2.4.19, I came across two 
> DIFFERENT ways of changing the state of the current task in do_select(): 
> 
>             set_current_state = TASK_INTERRUPTIBLE;
>      AND    current->state = TASK_RUNNING; 
> 
> I am curious to know if the second line of code doesn't cause any problem in 
> SMP systems.  I also see the same situation in do_poll().

You normally want to use set_current_state(), which is a nice
abstraction and safe for SMP.

Sometimes it is safe to use __set_current_state(), which does not
provide a memory barrier.

The above open-coded line can be changed to
__set_current_state(TASK_RUNNING).

	Robert Love

Re: Inconsistency in changing the state of task ??

[prash_t]

Thanks Robert for the reply.
But I notice that __set_current_state() is same as current->state. So, I 
didn't understand the safety factor on using __set_current_state( ). 

Also why should I use __set_current_state() instead of set_current_state() 
when the later is SMP safe. 

Thanks in advance....
Prashanth 

Robert Love writes: 

> On Tue, 2003-03-04 at 03:36, prash_t@softhome.net wrote: 
> 
>>      while browsing through fs/select.c file of 2.4.19, I came across two 
>> DIFFERENT ways of changing the state of the current task in do_select():  
>> 
>>             set_current_state = TASK_INTERRUPTIBLE;
>>      AND    current->state = TASK_RUNNING;  
>> 
>> I am curious to know if the second line of code doesn't cause any problem in 
>> SMP systems.  I also see the same situation in do_poll().
> 
> You normally want to use set_current_state(), which is a nice
> abstraction and safe for SMP. 
> 
> Sometimes it is safe to use __set_current_state(), which does not
> provide a memory barrier. 
> 
> The above open-coded line can be changed to
> __set_current_state(TASK_RUNNING). 
> 
> 	Robert Love 
> 
 

Re: Inconsistency in changing the state of task ??

[Richard B. Johnson]

On Thu, 6 Mar 2003 prash_t@softhome.net wrote:

> Thanks Robert for the reply.
> But I notice that __set_current_state() is same as current->state. So, I 
> didn't understand the safety factor on using __set_current_state( ). 
> 
> Also why should I use __set_current_state() instead of set_current_state() 
> when the later is SMP safe. 
> 
> Thanks in advance....
> Prashanth 
[SNIPPED...]

Usually, it would not make any difference. However, there is a
de facto standard to not use "__functions" or "__macros" directly
in code. Those are the things that the integrator will change to
accommodate different configurations, i.e., whether you are running
on a '386, '686, PPC or Sparc, SMP/High-memory, etc. So, you use
function() instead of _function() or __function().  If you use this
standard you might start out with this in some header:

#define function(p)  __function(p)

But in SMP machines, you might need some other code. Rather than
you having to modify your source, some header changes the definition
and it might become:

#define function(p) do{ MB(); __function(p); } while (0)

How, if you had executed __function() directly in your code,
you end up tossing that driver into the scrap-heap until it
gets fixed for SMP.


Bottom line; Look at the headers. If you have a choice, don't
use a function or macro that has leading underscores. If you
copy "working" drivers, you can be copying latent bugs. Don't
blindly go where others have gone (Star-Trek fans blink).


Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.

Re: Inconsistency in changing the state of task ??

[Robert Love]

On Thu, 2003-03-06 at 08:11, prash_t@softhome.net wrote:

> Thanks Robert for the reply.
> But I notice that __set_current_state() is same as current->state. So, I 
> didn't understand the safety factor on using __set_current_state( ). 

There is no safety with __set_current_state().  It is just an
abstraction.

The safety comes from set_current_state(), which ensures memory
ordering.

This is an issue not just on SMP, but on a weakly ordered processor like
Alpha.

> Also why should I use __set_current_state() instead of set_current_state() 
> when the later is SMP safe.

You only use __set_current_state() if you know you do not need to ensure
memory ordering constraints.

	Robert Love

RE: Inconsistency in changing the state of task ??

[Perez-Gonzalez, Inaky]

> > Thanks Robert for the reply.
> > But I notice that __set_current_state() is same as current->state. So, I
> > didn't understand the safety factor on using __set_current_state( ).
> 
> There is no safety with __set_current_state().  It is just an
> abstraction.
> 
> The safety comes from set_current_state(), which ensures memory
> ordering.
> 
> This is an issue not just on SMP, but on a weakly ordered processor like
> Alpha.
> 
> > Also why should I use __set_current_state() instead of
> set_current_state()
> > when the later is SMP safe.
> 
> You only use __set_current_state() if you know you do not need to ensure
> memory ordering constraints.

Man, I forgot how many times I have already posted the patch to fix this ...

Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own
(and my fault)