469,599 Members | 2,874 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,599 developers. It's quick & easy.

Atomic Operation?

Hello -

I was wondering if there is a simple way of ensuring that some
statements are executed as an "atomic operation". Here is what I am
dealing with in a GUI ...

Dim mAppDomain As AppDomain

The following sets the mAppDomain in a function ...
mAppDomain = AppDomain.CreateDomain(lFullPathAssembly)
.... and does other stuff with it ...

The problem is when for whatever reason the GUI is closed while the
above is running and the above causes an exception that sets the
mAppDomain to Nothing.

Protected Overrides OnClosing(...)
If Not (mAppDomain Is Nothing) Then
AppDomain.Unload(mAppDomain)
mAppDomain = Nothing
End If
...

What could potentially happen is that the mAppDomain is set to Nothing
between the If Not () Then and the Unload() call.

Is there a way to make the If() and Unload() calls atomic so that
nothing else can be done with mAppDomain in between those calls?

Thanks!
Joe

Aug 25 '06 #1
7 3191
I was wondering if there is a simple way of ensuring that some
statements are executed as an "atomic operation". Here is what I am
dealing with in a GUI ...

Dim mAppDomain As AppDomain

The following sets the mAppDomain in a function ...
mAppDomain = AppDomain.CreateDomain(lFullPathAssembly)
.... and does other stuff with it ...

The problem is when for whatever reason the GUI is closed while the
above is running and the above causes an exception that sets the
mAppDomain to Nothing.

Protected Overrides OnClosing(...)
If Not (mAppDomain Is Nothing) Then
AppDomain.Unload(mAppDomain)
mAppDomain = Nothing
End If
...

What could potentially happen is that the mAppDomain is set to Nothing
between the If Not () Then and the Unload() call.

Is there a way to make the If() and Unload() calls atomic so that
nothing else can be done with mAppDomain in between those calls?
There is no way to make them atomic in the sense you mean. You have two
choices. First, you can guard mAppDomain with a mutex. In all places in
code where mAppDomain is referenced, acquire the mutex, do your thing, and
release the mutex. Second, you could put the code you are worried about in a
Try-Catch block, and if the exception is the null reference exception, you
ought to be able to clean up in Catch without causing any downstream problems.
Aug 25 '06 #2
Joe HM wrote:
I was wondering if there is a simple way of ensuring that some
statements are executed as an "atomic operation".
What could potentially happen is that the mAppDomain is set to Nothing
between the If Not () Then and the Unload() call.
Is there a way to make the If() and Unload() calls atomic so that
nothing else can be done with mAppDomain in between those calls?
The "Visual Basic" way is to use the SyncLock keyword.

The full-blown Framework'y way would be a Mutex object.

HTH,
Phill W.
Aug 25 '06 #3
Hello -

Yeah ... I figured I could use Try/Catch in that case. I will look
into it some more and maybe use a Mutex if necessary.

Thanks guys!
Joe
AMercer wrote:
There is no way to make them atomic in the sense you mean. You have two
choices. First, you can guard mAppDomain with a mutex. In all places in
code where mAppDomain is referenced, acquire the mutex, do your thing, and
release the mutex. Second, you could put the code you are worried about in a
Try-Catch block, and if the exception is the null reference exception, you
ought to be able to clean up in Catch without causing any downstream problems.
Aug 25 '06 #4
"Joe HM" <un*******@yahoo.comschrieb:
I was wondering if there is a simple way of ensuring that some
statements are executed as an "atomic operation". Here is what I am
dealing with in a GUI ...

Dim mAppDomain As AppDomain

The following sets the mAppDomain in a function ...
mAppDomain = AppDomain.CreateDomain(lFullPathAssembly)
... and does other stuff with it ...

The problem is when for whatever reason the GUI is closed while the
above is running and the above causes an exception that sets the
mAppDomain to Nothing.

Protected Overrides OnClosing(...)
If Not (mAppDomain Is Nothing) Then
AppDomain.Unload(mAppDomain)
mAppDomain = Nothing
End If
...

What could potentially happen is that the mAppDomain is set to Nothing
between the If Not () Then and the Unload() call.

Is there a way to make the If() and Unload() calls atomic so that
nothing else can be done with mAppDomain in between those calls?
\\\
Private m_LockObject As New Object()

Protected Overrides Sub OnClosing(...)
SyncLock m_LockObject
If Not (mAppDomain Is Nothing) Then
AppDomain.Unload(mAppDomain)
mAppDomain = Nothing
End If
End SyncLock
End Sub
///

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>
Aug 25 '06 #5

Joe HM wrote:
Hello -

I was wondering if there is a simple way of ensuring that some
statements are executed as an "atomic operation".
Use SyncLock or Monitor.Enter and Monitor.Exit.
Here is what I am dealing with in a GUI ...

Dim mAppDomain As AppDomain

The following sets the mAppDomain in a function ...
mAppDomain = AppDomain.CreateDomain(lFullPathAssembly)
... and does other stuff with it ...
Where is this executing? I'm assuming it's on a thread other than the
main UI thread. Is that correct?
The problem is when for whatever reason the GUI is closed while the
above is running and the above causes an exception that sets the
mAppDomain to Nothing.

Protected Overrides OnClosing(...)
If Not (mAppDomain Is Nothing) Then
AppDomain.Unload(mAppDomain)
mAppDomain = Nothing
End If
...

What could potentially happen is that the mAppDomain is set to Nothing
between the If Not () Then and the Unload() call.
The only way that could happen is if the previous code snippet you
provided is executing on another thread.
Is there a way to make the If() and Unload() calls atomic so that
nothing else can be done with mAppDomain in between those calls?
Yes, you must wrap both code snippets with a lock by using the SyncLock
keyword. Its not guarenteed to work if you only wrap the contents of
the OnClosing method.
Thanks!
Joe
Aug 25 '06 #6

Phill W. wrote:
Joe HM wrote:

The "Visual Basic" way is to use the SyncLock keyword.

The full-blown Framework'y way would be a Mutex object.

HTH,
Phill W.
Phill,

Actually, SyncLock is the "full-blown Framework'y" way of doing it. A
Mutex is typically used to synchronize access to a resource shared by
multiple processes.

Brian

Aug 25 '06 #7
Hello -

Thanks for the feedback. Yes ... I am using multiple threads. I will
give SyncLock or Monitor.Enter/Exit a try.

Thanks!
Joe
Brian Gideon wrote:
Joe HM wrote:
Hello -

I was wondering if there is a simple way of ensuring that some
statements are executed as an "atomic operation".

Use SyncLock or Monitor.Enter and Monitor.Exit.
Here is what I am dealing with in a GUI ...

Dim mAppDomain As AppDomain

The following sets the mAppDomain in a function ...
mAppDomain = AppDomain.CreateDomain(lFullPathAssembly)
... and does other stuff with it ...

Where is this executing? I'm assuming it's on a thread other than the
main UI thread. Is that correct?
The problem is when for whatever reason the GUI is closed while the
above is running and the above causes an exception that sets the
mAppDomain to Nothing.

Protected Overrides OnClosing(...)
If Not (mAppDomain Is Nothing) Then
AppDomain.Unload(mAppDomain)
mAppDomain = Nothing
End If
...

What could potentially happen is that the mAppDomain is set to Nothing
between the If Not () Then and the Unload() call.

The only way that could happen is if the previous code snippet you
provided is executing on another thread.
Is there a way to make the If() and Unload() calls atomic so that
nothing else can be done with mAppDomain in between those calls?

Yes, you must wrap both code snippets with a lock by using the SyncLock
keyword. Its not guarenteed to work if you only wrap the contents of
the OnClosing method.
Thanks!
Joe
Aug 30 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

42 posts views Thread by Shayan | last post: by
3 posts views Thread by Zeng | last post: by
6 posts views Thread by blackstreetcat | last post: by
1 post views Thread by spacehopper_man | last post: by
11 posts views Thread by japhy | last post: by
2 posts views Thread by Freedom fighter | last post: by
10 posts views Thread by Dmitriy V'jukov | last post: by
11 posts views Thread by Jon Harrop | last post: by
reply views Thread by suresh191 | last post: by
4 posts views Thread by guiromero | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.