Hi Ed On Wed, Jun 23, 2010 at 3:18 PM, Grissom, Edward (Ed) <ed.gris...@intergraph.com> wrote: > In a previous message, Martin said: > >> So my only problem is to avoid concurrent reads from >> both main thread and worker thread. How can be this >> best accomplished without serializing the access? > > Your reads are eventually going to be serialized by the disk controller > anyway, so what is the problem with serializing the access ? Just do > it on a small enough scale that no thread gets starved.
You're right, but that is not what I had in my mind, sorry for being unclear. When rendering from worker thread, I have to avoid this kind of situations (considering one layer): 1. worker thread calls layer's ResetReading, then starts issuing GetNextFeature calls 2. before worker thread is done, main thread calls layer's ResetReading and also starts reading features 3. both main thread and worker thread do GetNextFeature calls, but both get invalid results This can happen e.g. when user tries to identify some features on map while rendering is in progress. With the "serialization of access" I meant serializing the calls: if main thread was going to read features, it would first wait until rendering of that layer finishes in worker thread. Clearly, with serialized access, there wouldn't be much added value when using threading. So, my main question is, if opening the same layer for worker thread is a safe operation. That is, if both main and worker thread will access (with GetNextFeature calls) their own copy of the layer, whether they both end up with correct data. Regards Martin _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev