acquire semaphore gives error Code = 0

[Jim West]

I have incorporated a semaphore into our software.  The semaphore protection works fine for a little while then gives a mysterious error code = 0.  From that point on, no semaphore operations will work correctly.  Has anyone ever seen this error?  Any clue what it might mean.  There is no message included with the error.

During Debugging I incorporated a mechanism to destroy that semaphore and get a new one.  I found that I can create a new semaphore but when the new semaphore is used, the reference is invalid.  I am using unique named semaphores.  I'm thinking that once the error occurs, the semaphore core is somehow corrupted.

This is occurring in built code running on windows server 2003.

Jim West

Summitek Instruments

[tst]

0 means no error which is why you would not see additional information.

Is this reliably reproducible? Can you upload example code?

Does it happen only in an executable running on 2003 or will it also happen in an EXE running on Vista\XP or in LV itself?

If so, I doubt you would get a great deal of help from NI, because 2003 is not officially supported.

[Jim West]

I screwed up a little.  I had coded to log an error if there was a error or semaphore timeout.  I jumped to the conclusion that it was an error.

I was passing around the semaphore reference as a global then acquiring the semaphore in which ever VI wanted to access the item.  Perhaps there is a flaw in passing around the reference.  At some point, the semaphore is not released leading to a TMO.  Thinking I would test this out, I wrote a little task that would destroy the existing semaphore the get a new one.  The new semaphore reference is placed in the global.  I have found that the reference is invalid when used.  I am using unique names each time.  I am very puzzled.

I have thought of two possible paths.  Create/destroy a named semaphore each time but that seems to have unneccsary overhead.

I also found a library of 'system' semaphores that use the kernel32.dll.

Any comment.

Jim West

[tst]

Using globals to pass a reference is not a good thing due to race conditions potential.

It seems to me that since the create semaphore VI is actually a create\lookup VI, you can basically just use it each time without calling destroy, but if you don't want the overhead of calling the CIN node, you can probably use something like this to acquire your reference.

In any case, it's important to be aware that a semaphore is only valid as long as the top level VI in the hierarchy which originally created it is in memory.

[Jim West]

I'm not following the reasoning that there is a race condition. It seems to me that if the semaphore works as advertised... meaning that the "Test and Set" action is correct.  There can never be a race condition of the kind that multiple processes lock the same semaphore.

In my webserver, there are two pieces to the puzzle.  The server that creates/destroys the semaphore and the processes that acquire/release the semaphore.

The main server, which is always running, creates a named semaphore.  Places that reference in a global.  Let's called it REF.  On shutdown, the semaphore is destroyed.

When running, a user requests a web page which then spawns off another handler process using a VI template (VIT).  Within this vi instance, the REF is used to Acquire the semaphore, do the protected action, and release the semaphore.  This will happen hundreds of times with no error.  Then, at some point an acquire is called and the acquire semaphore times out.  You can be sure that I have instrumented the code in such a way to tell me if a release failed or some other error.

One possibility is that the VIT instance spontaneously exits after the semaphore is acquired.  I don't believe that this is happening but there would not be any way to 'log' that behaviour.

It is possible that multiple VITs will attempt to acquire the semaphore using REF.  But that is why I am using the semaphore, to stack up the acquires in a methodology similar to stacking on non-reentrant vis.

Jim West

[tst]

The race condition I was refering to was when you destroy the semaphore and create a new one. In the time in between these two actions, one of your vit instances could try accessing the semapore and will get the error 1.

As for the timeout, is it possible that one of your templates simply didn't finish processing in time? Does the process they are performing have the potential of taking more time than the timeout requires or does a timeout absolutely means that something fails. Can you create a log which will show the time it took each process to go through its different steps? That way, you might be able to pinpoint this to a specific action which delays the vit.

Also, do you have a process monitor which will show all the currently opened templates?

[Jim West]

First,  I don't destroy and create the semaphore.  I merely acquire and release the same semaphore in different processes.  I can confirm that got the 1 error when I attempted to do the destroy/create method.

I gambled yesterday and replaced all of the LabVIEW semaphores with a library (http://zone.ni.com/devzone/cda/epd/p/id/4490) that implements the windows system semaphores.  We based this on a comment on the reference page "LabVIEW semaphores are implemented in LabVIEW, rather than at the system level, so cannot be shared by separate processes. "  Amazingly, I ran my webpage loading test program and I got no errors last night.  That is good news since I have been battling this problem for a week and another cpp problem with the Storage.dll for six weeks.

The only comment I have on the system semaphore library is that the original designer didn't destroy the semaphore handle the right way.  They apparently can't find MS tech support.(http://msdn2.microsoft.com/en-us/library/ms724211.aspx)  I have fixed that issue.

I'm going to keep testing today; probably run the load program all weekend.

tst  - I appreciate your comments.  Needed some fresh thinking on it.

Jim

[tst]

In LabVIEW, a semaphore should be usable within an application instance. In an executable, this would be the entire executable, but not seperate executable. If it worked until now, that means you were using a single executable and you probably still have a bug somewhere.

You did say in the original post that if the semaphore is invalid you destroy it and create another.

In any case, you should remember that 2003 is not supported, so it is possible that the problem is inherent.