Thread-safety in mapscript_csharp.dll?

[Tamas Szekeres]

Hi,

MapServer was originally created to use in a single threaded
application model, mapserv.exe is a single threaded CGI application.
Using mapserver in a multithreaded environment should be handled with
care.

At the programmer's perspective when using the IIS ASP.NET
implementation every request may be handled by different thread taken
out from a pool of threads.
During the creation of the first mapscript object the
mapscript_csharp.dll (hosting the C# part of the interface) will be
loaded into the executing appdomain.
The interface uses P/Invoke to access the C part of the interface
incorporated by the unmanaged mapscript.dll.  mapscript.dll will load
the subsequent dll-s needed for the
functionality of the application depending on the libraries enabled on
the compilation.
Every host process (aspnet_wp.exe or w3wp.exe) will have one instance
of the unmanaged dll-s loaded. You may have different application
domains with logically separated managed assemblies but all off these
assemblies will share the same unmanaged dll-s.

Most of the mapscript C# objects implement IDisposable and hold a
reference to an unmanaged memory segment.

One should take into account the following issues:

1. Since these unmanaged dll-s are using shared (global) variables and
resources, multiple requests will use the same variables from
different threads, and should be protected by locks.
2. Mapscript objects members are not syncronized by locks so passing
these objects between threads is to be avoided.
3. Mapscript objects should be properly disposed if not needed any more.

Considering the previously mentioned facts we should draw at least the
following conclusions:

1. Thread support should be enabled when compiling mapserver and
mapscript C#. It will enable the locks on the shared variables for the
most important components.
Some of the components are not protected this way so those items
should be avoided. See
http://mapserver.gis.umn.edu/docs/faq/thread_safety for more details.
2. One should compile with only the features really needed by the application.
3. Should not retain mapscript objects between requests (eg. using in
session variables).
4. Should use IDisposable.Dispose or the using{} clause to properly
deallocate the unmanaged memory.

Some of these conclusions may also apply to other languages using
multithreaded application models.

We are making some effort to eliminate the need of those variables and
using "big locks" to increase the performance of the applications in
multithreaded environments. To achieve this level most of the existing
code should be reviewed.
The first step for this activity was recorded at
http://mapserver.gis.umn.edu/development/rfc/ms-rfc-15/ and will be
enhanced upon the user's and developer's affinity for this issue. I'm
considering few of the folks using mapserver and mapscript this way or
they aren't complaining about much of these problems so far.


Best Regards,

Tamas Szekeres


2006/6/23, Jeff Dege <jdege at korterra.com>:
> I'm just beginning with mapserver, and I'm evaluating different
> possibilities.
>
> In our shop, Windows/IIS/ASP.NET/C# would be the preferred approach.
>
> Using the compiled ASP.NET 1.1 DLLs from MS4W, I've had no difficulty
> getting mapscript_csharp.dll to work.
>
> But the docs are full of warnings about lack of thread safety.  The
> installation instructions for PHP_mapscript indicate that PHP should be
> installed to run in CGI mode, rather than in ISAPI mode, so that a
> separate instance of the mapscript DLLs are loaded for each request -
> because the mapscript DLLs aren't threadsafe.
>
> I'm assuming that the problem is still there when using the C# wrappers.
> Is there something I need to do, when using mapscript_csharp.dll from
> IIS, to prevent this problem?  Something I need to set in the
> configuration or the code so that the ASP.NET pages are run as CGI?
>
> I'd really hate to waste too much time building on top of
> mapscript_csharp, only to find that it won't work reliably once multiple
> users start accessing it.
>
> Answers, or pointers to docs, would be appreciated.
>
> Thanks.
>