Tile manager and Mutex and desinging for threading

[Cyrille Berger]

Hello,

I have been doing some benchmark on the the tilemanager of Krita2. And it 
appears (with callgrind and sysprof) that the calls to QMutex::lock/unlock 
are quiet costly. Especially that, currently, for each call to the data 
manager, we end up making around 3 or 4 calls (and to achieve that, I have 
reduced the number of mutex, one safely by using only the bigKritaLock in the 
tiledatamanager, and one more dangerously by removing the locks in KisTile).

And looking at the call graph, no matter what you do, each time you want to 
access the tile manager, very soon, the whole datamanager is locked. So I was 
wondering if having one lock in the datamanager, locking it each time before 
we request something from it. Basicaly, three classes are accessing the 
datamanager: KisPaintDevice, KisTiledIterator and KisTiledRandomAccessor.

I am also wondering if giving access to a tile to two threads is a good idea. 
Basically we have three case:
- read/read two threads are reading the tile
- read/write one thread is reading while one other is altering
- write/write two threads are writting

read/read is ok. But the other two are a call to get problems. So do we want 
to allow read/read, or a simple locking of the tile would be enought ?

-- 
Cyrille Berger