[rvm-research] scan threads array without lock

[Anthony Hocquet]

Hello everybody,

I'm interested in scanning threads[] array from RVMThread to get access to a variable from each thread. Typically, my code looks like :
      for (int i = 0 ; i < numThreads ; i++) {                                                                                                                                                          
        if (!notRunning(threads[i].getExecStatus())) {                                                                                                                                                  
          for (int j = 0 ; j < threads[i].buffer_size ; j++) {                           
            compute(threads[i].buffer[j]);
        }                                                                                                                                                                                               
      }                 

The thing is that numThreads may be modified when a Thread is created or destroyed. In the latter case, my code will try to access to a bad array index in threads[].
So, I added before and after the external for loop :
 
  RVMThread.acctLock.lockNoHandshake();                 
  for (int i = 0 ; i < numThreads ; i++) { ... }
  RVMThread.acctLock.unlock();                                                                                                                                                                      
   
But I would like to avoid this lock. Indeed, this code is executed in a while(true) loop, and may highly delay thread creation/destruction.

I've read in RVMThread that it's possible to process the threads array, in a comment from releaseThreadSlot() method :
                  /*                                                                                                                                                                                    
                   * make sure that if someone is processing the threads array                                                                                                                          
                   * without holding the acctLock (which is definitely legal)                                                                                                                           
                   * then they see the replacementThread moved to the new index                                                                                                                         
                   * before they see the numThreads decremented (otherwise they                                                                                                                         
                   * would miss replacementThread; but with the current                                                                                                                                 
                   * arrangement at worst they will see it twice)                                                                                                                                       
                   */           

Does anybody know how can I do that?

Best regards,
--
Anthony Hocquet

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Jikesrvm-researchers mailing list
Jikesrvm-researchers@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

[Filip Pizlo-2]

I wrote that comment. :-)  And I'm not sure it's totally true.  There  
are many potential races that can happen.  But if you don't care about  
being guaranteed every time that you see every thread, or that you see  
each thread only once, then you can try to do this without the lock.  
It would look something like this:

for (int i=numThreads-1;i>=0;i--) {
    RVMThread t = threads[i];
    if (t!=null) {
       // your usual code here, using t instead of threads[i]
    }
}

Another approach you could use is to create your own buffer of threads  
somewhere (i.e. your own RVMThread[]), and then while holding the  
acctLock, populate this buffer.  Then after releasing the acctLock, do  
what you need to do to the contents of the buffer.  This is the style  
in which RVMThread.hardHandshakeSuspend() is written, for example.

-Filip




On Sep 9, 2009, at 10:48 , Anthony Hocquet wrote:

> Hello everybody,
>
> I'm interested in scanning threads[] array from RVMThread to get  
> access to a variable from each thread. Typically, my code looks like :
>       for (int i = 0 ; i < numThreads ; i++) {
>         if (!notRunning(threads[i].getExecStatus())) {
>           for (int j = 0 ; j < threads[i].buffer_size ; j++) {
>             compute(threads[i].buffer[j]);
>         }
>       }
>
> The thing is that numThreads may be modified when a Thread is  
> created or destroyed. In the latter case, my code will try to access  
> to a bad array index in threads[].
> So, I added before and after the external for loop :
>
>   RVMThread.acctLock.lockNoHandshake();
>   for (int i = 0 ; i < numThreads ; i++) { ... }
>   RVMThread.acctLock.unlock();
>
> But I would like to avoid this lock. Indeed, this code is executed  
> in a while(true) loop, and may highly delay thread creation/
> destruction.
>
> I've read in RVMThread that it's possible to process the threads  
> array, in a comment from releaseThreadSlot() method :
>                   /*
>                    * make sure that if someone is processing the  
> threads array
>                    * without holding the acctLock (which is  
> definitely legal)
>                    * then they see the replacementThread moved to  
> the new index
>                    * before they see the numThreads decremented  
> (otherwise they
>                    * would miss replacementThread; but with the  
> current
>                    * arrangement at worst they will see it twice)
>                    */
>
> Does anybody know how can I do that?
>
> Best regards,
> --
> Anthony Hocquet
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
> 30-Day
> trial. Simplify your report design, integration and deployment - and  
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july_______________________________________________
> Jikesrvm-researchers mailing list
> Jikesrvm-researchers@...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Jikesrvm-researchers mailing list
Jikesrvm-researchers@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

[Anthony Hocquet]

Hi Filip!

Every time I have a situation, you're the one who solves it :-)
Indeed, your code is working because I'm holding thread reference.

Thanks you very much Filip, as usually :)

Cheers

Wed, Sep 9, 2009 at 5:47 PM, Filip Pizlo <pizlo@...> wrote:

I wrote that comment. :-)  And I'm not sure it's totally true.  There
are many potential races that can happen.  But if you don't care about
being guaranteed every time that you see every thread, or that you see
each thread only once, then you can try to do this without the lock.
It would look something like this:

for (int i=numThreads-1;i>=0;i--) {
   RVMThread t = threads[i];
   if (t!=null) {
      // your usual code here, using t instead of threads[i]
   }
}

Another approach you could use is to create your own buffer of threads
somewhere (i.e. your own RVMThread[]), and then while holding the
acctLock, populate this buffer.  Then after releasing the acctLock, do
what you need to do to the contents of the buffer.  This is the style
in which RVMThread.hardHandshakeSuspend() is written, for example.

-Filip

On Sep 9, 2009, at 10:48 , Anthony Hocquet wrote:

> Hello everybody,
>
> I'm interested in scanning threads[] array from RVMThread to get
> access to a variable from each thread. Typically, my code looks like :
>       for (int i = 0 ; i < numThreads ; i++) {
>         if (!notRunning(threads[i].getExecStatus())) {
>           for (int j = 0 ; j < threads[i].buffer_size ; j++) {
>             compute(threads[i].buffer[j]);
>         }
>       }
>
> The thing is that numThreads may be modified when a Thread is
> created or destroyed. In the latter case, my code will try to access
> to a bad array index in threads[].
> So, I added before and after the external for loop :
>
>   RVMThread.acctLock.lockNoHandshake();
>   for (int i = 0 ; i < numThreads ; i++) { ... }
>   RVMThread.acctLock.unlock();
>
> But I would like to avoid this lock. Indeed, this code is executed
> in a while(true) loop, and may highly delay thread creation/
> destruction.
>
> I've read in RVMThread that it's possible to process the threads
> array, in a comment from releaseThreadSlot() method :
>                   /*
>                    * make sure that if someone is processing the
> threads array
>                    * without holding the acctLock (which is
> definitely legal)
>                    * then they see the replacementThread moved to
> the new index
>                    * before they see the numThreads decremented
> (otherwise they
>                    * would miss replacementThread; but with the
> current
>                    * arrangement at worst they will see it twice)
>                    */
>
> Does anybody know how can I do that?
>
> Best regards,
> --
> Anthony Hocquet

> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july_______________________________________________
> Jikesrvm-researchers mailing list
> Jikesrvm-researchers@...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Jikesrvm-researchers mailing list
Jikesrvm-researchers@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

--
Anthony Hocquet

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Jikesrvm-researchers mailing list
Jikesrvm-researchers@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers