Is MapServer Thread-safe?

[Tamas Szekeres]

2008/1/21, adrian kruk <adrian.kruk at gmail.com>:
>
>
> After reading article  'Is MapServer Thread-safe?' in FAQ I have doubts.
>
> My question is what means that some component is unsafe, I don't know
> architecture of mapserver and I don't need to know.
>
> So listed unsafe components telling me nothing except my imagination what
> these components are doing.
>

Hi,

Actually there are many places inside the code may use global
resources (eg. variables) that should be protected from the
simultaneous access from multiple threads. This may apply as well to
any of the dependent libraries (dll-s) that mapscript actually use.
If a dll is loaded by the application (by the ASP.NET host process in
this case), then these resources are shared among the threads within
the same host process.
Many of the shared reasouce accesses are protected by locks inside the
mapserver core if the USE_THEAD option is enabled during the
compilation. However there are a few mapserver components and
dependent libraries which may continue to use the global resources
without protection. Those components were declared as thread unsafe.

> Answer for the question need also some examples of code (e.g. some
> workarounds in C# with using mapscript_csharp)
>

The problem is not related to the C# interface, so you cannot control
the access to these resources from the c# interface. However you can
minimize the multi-thread access to the mapscript classes as much as
you can. For example you can resonstruct the map object in every
subsequent requests, or create a clone of the object stored in a
session variable at the beginning of each request.

In some cases we could possibly restructure the application for
creating different processes for the map generation (1 worker
thread/process accesses the mapscript objects) and set up a
communication protocol between the ASP.NET application and the process
pool.

> I have this kind of situation:
>
>
> I 'm created ASP.NET application and I'm using mapscript_csharp dll.
> Each of browser clients will have its own map object instance stored in
> session cache. So each client request is creating new thread on IIS server.
>
> So, new client must wait for its map object if mapscript is just creating
> map object for other client (other thread), even if server has many
> processors? Becouse of Map config file loading its global parser and it is
> locked. I Am wrong?
>

Yes, and it may affect the overall performance. However these cricital
sections may be quite limited in duration and the possibility that the
threads wait each other might not be significant in many cases.

> The same situation after some time. Two clients (two threads on server)
> requests for image calling map.draw(). This is unsafe situation becouse of
> 'some static data in Imagemap output'?
>

Using the unsafe portions of the code should be avoided. Accessing
unprotected resources by different threads may result in access
violation issues.


The most reasonable solution would be to reimplement the critical code
segments so as to allow multithread access, definitely. MS RFC 15 have
been addressed this goal
http://mapserver.gis.umn.edu/development/rfc/ms-rfc-15

However it would require much more effors to realize than expected before.

Best regards,

Tamas