[Gdal-dev] Multi-threading Support

[Frank Warmerdam]

On 6/8/05, Marek Brudka <mbrudka at aster.pl> wrote:
> The solution above works nicely for us. It costs 30 minutes (with
> compilation) of work if CPLMutex and CPLMutexGuard are avalaible.

Marek,

I have committed a change to ogrct.cpp to protect PROJ.4 calls 
with a mutex.  If you see problems with my implementation please correct.
 
> I have a proposition, I made already once. Frank, make
> GDAL dependent on boost library. 

I remain unprepared to make such a shift though I can see the
advantages you have enumerated. 
 
> I have also one question. Could you give me write access to gdal
> CVS, please? 

Done, as per private email.

> Why? In my company we GDAL in our CVS repo,
> because we have to remove GDAL bugs by our own (especially in
> multithread, memory management and reference counting). I do not
> need GDAL CVS access for this, but it's just a pity these changes
> are not avalaible for GDAL community. I also do not like merging our
> changes
> with each new GDAL release. Let me mention also I'm too
> busy to report and discuss such bugs each time I recognize or fix them.
> A bug report and a discussion which usually follows it takes more time
> than fixing bugs! It is not the best way to develop the software.

Generally speaking I am happy to provide responsible developers
with CVS commit access to GDAL.  The caveat is that I am still quite
possesive about GDAL so I would prefer you not apply potentially
controversial changes without prior discussion.  Sometimes my resistance
to change is bad for progress in GDAL, but at least it ensures I stay 
comfortable with the library and ensures I am prepared to take responsibility
for it as a whole. 

> BTW. There is a serious design problem with reference counting and
> memory management in multithread GDAL applications. It makes
> the read only sharing of OGRSpatialReference ( and remaining
> reference counted classes ) between threads almost impossible . This
> problem is a direct implication of lack of correct reference counting via
> intrusive smart pointer classes as well as by invalid convention for
> mutexes.

I am aware of the problems with reference management of OGRSpatialReferences
and I agree something needs to be done.  The caveat is that many existing
OGR drivers need to be reviewed very carefully to ensure proper use of
OGRSpatialReference as part of this change.  
 
Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent