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

Re: A proposed solution for svn admin directory names

From: Joseph Galbraith <galb_at_vandyke.com>
Date: 2005-06-29 20:26:40 CEST

C. Michael Pilato wrote:
> Philip Martin <philip@codematters.co.uk> writes:
>>Joseph Galbraith <galb@vandyke.com> writes:
>>>Garrett Rooney wrote:
>>>>Static variables like that are not especially thread safe.
>>>Ahh... I think my second code snippet address this problem
>>>as it does away with the bool and only uses the szAdmDir...
>>>I'll quote it here for clarity:
>>>char* getadmdir()
>>> static char* szAdmDir = 0;
>>> if ( szAdmDir == 0 )
>>> {
>>Pointers are probably atomic on all the platforms that run Subversion,
>>but strictly speaking it's not guaranteed and depends on the
> I'll demonstrate a little ignorance here, perhaps, but isn't thread
> safety all about making sure different threads wouldn't get different
> data or stomp on each other's data? It would seem that this wouldn't
> really be likely to happen here. If you can safely assume that all
> threads of a single application would have the same environment (which
> might not be a safe assumption?), then at any given time, each thread
> would either have szAdmDir set to 0 or to some string which would have
> be the same string across all threads anyway.
> Now, about that ignorance -- what did I miss?

If pointers aren't atomic, a thread might see szAdmDir as part 0 and
part some new value that is only half written. And fall down go boom!

Do we have either:

a.) A initialization function, etc., where we are know we aren't
     multithreaded (i.e., a higher layer is responsible for either not
     having started addtional threads or providing the locking)

b.) A portable interlocked exchange function?



To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 29 20:22:22 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.