[Mapserver-dev] Recent progress on mapserver thread safety

[Sean Gillies]

Hi all,

I've just fixed three potential sources of threading trouble using
Frank's mapthread API.

- parsing expression strings outside of msLoadMap
- evaluating mapserver logical expressions
- loading symbol set files outside of msLoadMap

Issues of thread safety can now be divided into two separate application
phases: a "loading" phase and an "execution" phase, which is everything 
else.

During the loading phase, we acquire a parser lock immediately and 
release
it only after the entire mapfile has been loaded.  Within this phase we
will use parsing functions with no locking of their own, particularly
loadExpressionString, and loadSymbolSet.

Outside of the loading phase, we must use locking versions of these 
functions.
msLoadExpressionString and msLoadSymbolSet are wrappers for the previous
functions.  I've also added parser locking to msEvalExpression and 
msEvalContext,
and have changed all execution-phase code to use these parser locking
functions.

We are now safer, but still have a performance bottleneck.  The one
parser is shared between threads in mapfile loading and map rendering 
(or
"execution") phases.  In the first case a lock is held relatively long,
while in the second case it's acquired and released (inside 
msEvalExpression)
quickly with every call to msLayerNextShape.  I believe the tendency 
would be
for map rendering to be upstaged by mapfile loading when activity is 
high.

I see at least three solutions that we may want to consider for 4.4:

1) implement a second global parser for use in msEvalExpression

and/or

2) pull the parser locking out of msEvalExpression, and instead lock 
around
the loops which call msLayerNextShape.

or

3) rewrite msEvalExpression so that it doesn't need a parser for logical
expressions.

I'd love to get some feedback from folks who are interested in using
mapserver in a multithreaded environment.

Full issue thread is here:

   http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=339


cheers,
Sean


--
Sean Gillies
sgillies at frii dot com
http://users.frii.com/sgillies