[geos-devel] Issues with smart pointers and threads?

[Ferdinando Villa]

Right - it only matters if two+ threads can share a reference counted
pointer. Then you need to serialize the counter increment or you're in
big trouble. Most OS have kernel support for atomic increment that makes
it fast, and open sources implementations abound. If we're not going to
share geometries between threads then that's not necessary, but I don't
see how we can enforce that or why should we. I can think of various
applications where sharing geometries between threads or not could mean
major differences in efficiency.

We can use policy-based design to define the threading model at compile
time (that's what boost does) so that locking does not occur unless the
application needs it (even if there's good support from the OS, it's
going to be expensive compared to not doing it at all). As long as we
use some kind of template-based smart pointer instead of a custom
reference counter, we can always plug it in later unless postgis needs
it from the start - I'm happy to help, after June 20...

ciao 
f

On Tue, 2003-05-27 at 20:12, David Blasby wrote:
> I'm a bit concerned with using the reference counting since it could 
> cause us some grief.  However, if this open source reference counter is 
> good this might be easy.
> 
> Personally, I think wasting a wee bit of space for the precision model 
> in a geometry isnt going to be that big a deal.
> 
> As for thread-safety, consider this:
> 
> Single threaded application makes a PrecisionModel.
> This application forks 2 threads that both have access to this 
> PrecisionModel.
> Both threads create a bunch of geometries using the PrecisionModel.
> 
> If your reference counting is *not* thread-safe (ie. protected by a 
> semephore), then there is a race condition if both threads try to 
> increment the reference count at the same time.
> 
> dave
> 
> 
> _______________________________________________
> geos-devel mailing list
> geos-devel at geos.refractions.net
> http://geos.refractions.net/mailman/listinfo/geos-devel
-- 
Ferdinando Villa <fvilla at zoo.uvm.edu>
University of Vermont