Thread-safety in mapscript_csharp.dll?

[Fawcett, David]

That's the cool thing about opensource.  If your paying customers are
demanding new features, you can improve the code base yourself, or fund
someone to add the functionality for you.  

-----Original Message-----
From: UMN MapServer Users List [mailto:MAPSERVER-USERS at LISTS.UMN.EDU] On
Behalf Of Jeff Dege
Sent: Friday, June 23, 2006 4:06 PM
To: MAPSERVER-USERS at LISTS.UMN.EDU
Subject: Re: [UMN_MAPSERVER-USERS] Thread-safety in
mapscript_csharp.dll?


 

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