Re: [rvm-research] Native threading model

[Tony H. <ho...@cs...>]

Hi Laurence!

On 7 Apr 2009, at 03:47, Laurence Hellyer wrote:

> Hi,
>
> I'm trying to understand the native threading model and it's
> consequences for @Uninterruptible code
>
> As I understood it - previously under Green Threads on a n core  
> machine
> invoking the rvm with -X:vm:processors=1, code in a @Uninterruptible
> method would have been executed atomically as there was no possible  
> way
> for another thread to be scheduled.

Yes, that is true for processors=1, but generally not true for  
processors>1, so relying on Uninterruptible to enforce atomicity was  
never very good idea.  All uninterruptible really meant for  
processors>1 was that the code would not hit a yieldpoint within the  
uninterruptible reagion.  Another thread could still execute in  
parallel with that uninterruptible region on another processor.

> With native threading each Java thread is now it's own pthread...

In user threading, every running Java thread was also identified with  
a pthread (=processor).

> On a 1 logical processor machine am I right in thinking that an
> @Uniterruptible method is no longer guaranteed to execute atomically  
> and
> that another mutator thread could be scheduled to run part way through
> the @Uniterruptible method - the @Uninterruptible annotation merely
> disables yieldpoints which are responsible for handshakes with the GC

Correct.  Since system threads are scheduled by the system, they can  
yield to the system at any point in their execution, regardless of  
whether they are at a "yieldpoint" or not.

> What is the most efficient method to prevent other threads from  
> running
> whilst my @Uninterruptible method is running on a 1 core machine?

That depends on what you are trying to achieve.  There is no  
straightforwardly "efficient" way to do so now since we are prepared  
for multiprocessor execution.  Thus, you must use standard concurrent  
programming techniques: take a lock that protects the resource you are  
trying to prevent others from manipulating, or use other non-blocking  
synchronization constructed from synchronization primitives like CAS,  
etc.  There are plenty of places with the RVM that need to do this  
sort of thing, and you can browse for how they achieve it in their  
particular situation.  There is a heavyweight alternative, which is to  
stop all the other threads from running (just like stop-the-world GC  
needs to do), but I suspect in your situation that is not a price you  
want to pay.

> I noticed that the Wiki pages at:
> http://jikesrvm.org/Threading+and+Yieldpoints and
> http://jikesrvm.org/Thread+Management are sadly out of date - I would
> offer to up date them but as you might be able to tell I don't feel
> confident in this area of the RVM (yet)!

Indeed, these will need updating for the expected next release of  
Jikes RVM.

Cheers,

Tony

Antony Hosking | Associate Professor | Computer Science | Purdue  
University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484