[mapguide-internals] Race Condition in TileService - Synchronization Problems

[UV]

Hi,

a careful look and some testing of the sync code in MgServerTileService 
exposes that its not thread safe if requesting the same tile concurrently.
The sequence is:

1 DetectTileLockFile
2 CACHECHECK?

                    -CacheHit
                    3 RETURN TILE

+CacheMiss
3 MUTEX
4 DetectTileLockFile
5 CACHECHECK?

                    -CacheHit2
                    6 ENDMUTEX
                    7 RETURN TILE

+CacheMiss2
6 Create Lockfile            (the observed problem)
7 GetMapFromDefinition
8 ENDMUTEX
9 GetTile    | GetMetaTile
10                 renderTileFromMetaTile
11                 setTileCache
12 DeleteLockFile
13 RETURN TILE

The used mutex only protects the map deserialization and lock file creation.

There is a race condition between threads requesting the same tile. 
(this might lead to some multi-user unsafe behaviour observed by some users)
thread a + b do not find the lockfile
thread a carries on creating the tile
thread b might test for lockfile AGAIN before its created by a)
thread b fails with Lockfile error

WHAT TO DO?

Using more locks!
Currently the mutex used here is a static member of the service!
But using 1 lock by extending the mutex scope might seriously limit 
performance.    (i.e. using one lock for all tiles)

What about using some array of lock constructs which:
a) can be mapped from the tile coords.
b) could get mapped to sessions for multi-user scenarios (which we dont 
have on the server side in mapguide afaik)

So a group of adjacent tiles could share a lock.
How many tiles should share a lock?
This is where the direct relation to the meta tiling rfc90 comes in.
I was considering using signal/wait code in addition to file locks as 
the map sm_mutex is a bit coarse.

However, this depends on the cost of using additional locks which I am 
currently not aware of

Any suggestions?