[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r16244 - in trunk: . subversion/clients/cmdline subversion/include subversion/libsvn_client subversion/libsvn_wc subversion/svnversion subversion/tests/clients/cmdline subversion/tests/clients/cmdline/svntest tools/examples

From: Branko Čibej <brane_at_xbc.nu>
Date: 2005-09-26 12:53:24 CEST

Philip Martin wrote:

>Branko Čibej <brane@xbc.nu> writes:
>
>
>
>>Ah-ha. Yes, we have to use CAS because void* may not be atomic. But,
>>what's more, we have to use CAS _everywhere_, not just in
>>svn_wc_set_adm_dir. Using a NULL comparator and exchange value will
>>effectively change the CAS to an atomic read. That won't avoid the
>>race, but it will address your other concerns. (No, I'm not prepared
>>to assume that void* is atomic, _especially_ not on MP machines.)
>>
>>
>That sounds OK. The race is not a problem if there is some other
>reason for using CAS; it does look odd if the only reason for using
>CAS is to detect a race that is only present because CAS is being
>used.
>
>
That's an interesting way of putting it. :) See r16267.

>I think the use of CAS should be hidden from Subversion clients as far
>as possible. Since svn_wc_set_adm_dir doesn't care about the original
>value, and neither will a new svn_wc_get_adm_dir, I think the
>Subversion functions should loop until the CAS succeeds so that
>clients never need to handle APR_EAGAIN.
>
>
I thought about doing that, but decided not to because of the potential
of starting a CAS war between different threads. OTOH, since
svn_wc_set_adm_dir is really intended to be called in single-threaded
initialisation, that problem shouldn't turn up in practice. What I'd
suggest then is to:

    * Add the loop to the implementation
    * Change the function's docstring so that it mentions (but not
      requires) single-threaded initialisation.

Does that make sense?

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 26 12:54:20 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.