Re: [rvm-research] scan threads array without lock

[Anthony H. <ant...@gm...>]

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 <pi...@pu...> 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
> > Jik...@li...
> > 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
> Jik...@li...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>



-- 
Anthony Hocquet