perfsonar development work

[Loukik Kudarimoti <>]

I think this is an important point. I am really not sure if its 
something we need to worry about *at the moment* but its good to get the 
developers involved. Hence, opening this thread to the dev mailing list.

Roman, what are your thoughts on this?

Loukik.

Prodromos Gerakios wrote:
> Ilias Tsompanidis wrote:
> > Michael Michalis wrote:
> > > <snip>
> > > > >       
> > > > So, there should be no concurrency issue when the lying application
> > > > is thread safe. Which means that sql databases should have no
> > > > problem, but rrd might as librrd is not thread-safe (but i can't
> > > > seem to find a possible write concurrency, since lockfiles are used
> > > > by rrdtool, and... deletes are not supported) - This goes as far as
> > > > my knowledge  about the MAs allows.
> > > >     
> > >
> > >  
> > > > Ilias
> > > >     
> > > So to sum up and add to this point: The only services that can accept
> > > data are the MAs and the LS and thus these are the only services that
> > > concurrency problems may emerge. The concurrency issues for these
> > > services actually concern the underlying databases or files used for
> > > adding new data. In the case of the databases, these issues should
> > > have been addressed by the database developers(SQL,eXist). That leaves
> > > the case of the rrd files used in the RRD MA. A concurrency problem
> > > could emerge if two or more people tried to update the  rrd file for
> > > the same time value. Remember that rrdtool stores data in distinct
> > > time slots and the time interval between these slots is defined by the
> > > user. So if two or more people tried to update the same time slot then
> > > we would have a possible problem. But in the case of the RRD MA Store
> > > request, the service does not update the time slots based on the time
> > > the request has arrived but it uses the time stamp that comes with the
> > > data(a pair of data and time stamps).  So it really doesn't matter if
> > > two or more requests arrived simultaneously, what matters is which
> > > times slots these requests are trying to update and thats something
> > > that the service is not meant to handle.
> > >
> > > Best Regards,
> > > Michalis      
> > >   
> > By reading again Prodromos mail, I thought of another possible scenario.
> > "it is possible that multiple threads of control
> > may attempt to access your object's methods at the same time."
> >
> >   This might mean the same object (connector to DB) used by the 
> > service, might be used concurrently by two threads (even SELECT 
> > requests), and eventually create corrupted data:
> > Thread1 : Select A      (A in BUFFER)
> > Thread2 : Select B      (B in BUFFER)
> > Thread2 : read BUFFER (B in BUFFER)
> > Thread1 : Select A      (B in BUFFER) - thread1 wanted to read A
> >
> > (sigh). The joy of multi-threaded programming...
> > Ilias
> >
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v1.4.7 (MingW32)
> > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> > >  
> > > iD8DBQFHOpL+oEWq51/Q/40RAjqkAJ9AxAeQMol7ktI6Tcb9KvpFzrU30QCfXgfD
> > > xNWy7pvW0YGfZpiqH6WrXRk=
> > > =KQsG
> > > -----END PGP SIGNATURE-----
> > >   
> Hi all,
>
> I think Ilias is correct. That is, there may exist multiple "static" 
> objects or worse, shared objects which are accessible by different 
> threads of control. Consider the case of a linked list which is 
> accessible via a "global" variable (i.e. in Java terms a  static class 
> field). We don't want the threads to modify the linked list 
> concurrently. However it is impossible to test all possible 
> interleavings, as it would require considerable man-hours, and 
> therefore we should at least test concurrent request scenarios.
>
> Kind regards,
> Prodromos.


--

---------------------------------------------------------------
L o u k i k   K u d a r i m o t i

     * *              Network Engineer
   *     *            City House, 126 - 130, Hills Road
  *                   Cambridge CB2 1PQ, United Kingdom
  *                   WWW: http://www.dante.net
D  A  N  T  E          Tel:+44 1223 371300 Fax:+44 1223 371371