[mapguide-internals] Race Condition in TileService -
Synchronization Problems
UV
uvwild at googlemail.com
Sat Mar 27 00:22:35 EDT 2010
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?
More information about the mapguide-internals
mailing list