Thread#priority(=) will be obsolete

Hi,

We are planning to make Thread#priority(=) method as obsolete method
from Ruby 1.9.x. This is due to implimentation/practical (maybe no
one use it) reason.

Any comments?

On Tue, 2008-08-12 at 18:06 +0900, SASADA Koichi wrote:

We are planning to make Thread#priority(=) method as obsolete method
from Ruby 1.9.x. This is due to implimentation/practical (maybe no
one use it) reason.

Any comments?

Some way to reduce thread priority is important for situations like
idling work-stealing threads in a nonblocking/lockfree way, which is a
situation I’ve come up against recently.

-mental

Hi,

MenTaLguY wrote:

Some way to reduce thread priority is important for situations like
idling work-stealing threads in a nonblocking/lockfree way, which is a
situation I’ve come up against recently.

inserting sleep is not enough?

From: “SASADA Koichi” [email protected]

(optional-3: we should choose 1 or 2 on build/launch timing)
Interesting. This is what we’ve been doing on Unix systems
having pthreads. However, I’ve not actually empirically
verified it had any effect:

void set_thread_priority_low ()
{
struct sched_param sp;
int policy;

memset(&sp, 0, sizeof(struct sched_param));
pthread_getschedparam(pthread_self(), &policy, &sp);
sp.sched_priority = sched_get_priority_min(policy);
(void) pthread_setschedparam(pthread_self(), policy, &sp);

}

So when you say, “not affect on most UNIX environment” it makes
me wonder: does the above really work, or not? :slight_smile:

For completeness’ sake, here’s what we’re doing on Windows:

void set_thread_priority_low ()
{
SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_BELOW_NORMAL);
}

Personally I think it would be nice if ruby retained the
ability to say “make this thread low priority”, even if
the non-portable integer priority values are removed.

(However, if that pthread code really has no effect on
most Unix systems, then . . . . I dunno :slight_smile:

Regards,

Bill

On Wed, Aug 13, 2008 at 11:27:14AM +0900, SASADA Koichi wrote:

Hi,

MenTaLguY wrote:

Some way to reduce thread priority is important for situations like
idling work-stealing threads in a nonblocking/lockfree way, which is a
situation I’ve come up against recently.

inserting sleep is not enough?
No. In my application (a robot control framework), I have a control
thread a
multiple planning threads. The control thread MUST be prioritized vs.
the
planning thread, otherwise reaction to problems could be delayed because
of high
planning load – leading to a robot physical crash for instance :wink:

Thread priorities are useful. Please do not remove them (and sleeping is
really
a hack in case MenTaLguY described), given that in worst cases one would
do
nothing while CPU is available).

Sylvain