Thread-safety in mapscript_csharp.dll?

[Jeff Dege]

> -----Original Message-----
> From: Tamas Szekeres [mailto:szekerest at gmail.com] 
> Sent: Friday, June 23, 2006 3:32 PM
> To: Jeff Dege
> Cc: MAPSERVER-USERS at lists.umn.edu
> Subject: Re: [UMN_MAPSERVER-USERS] Thread-safety in 
> mapscript_csharp.dll?
> 
> 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.

I understand that.  It's just what care I'm unsure of.

> 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.

Are you suggesting that we should protect access to the mapserver
objects within the C# code, using the C# lock statement?  Or are the
locks within the mapscript_csharp.dll sufficient?

> 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.

Google has changed things.  Our customers are demanding mapping, and
demanding a more interactive mapping capability than they'd previously
been satisfied with.  I think you'll see a growing interest in running
mapscript with ASP.NET and ATLAS.