Kevin, I am running on WinXP with RB2005r4 and see the same as you when the code is called from the main program thread. If you place the code in another thread it suspends as you would expect. Perhaps this was done by design to prevent us from accidentally suspending the main thread, creating a deadlock and hanging the application. You might want to address this specifically to Aaron Ballman as he appears to be the RB guru in this area. He is more likely to respond if this is brought up in the forums.
Regards, John > -----Original Message----- > From: Kevin Windham [mailto:[EMAIL PROTECTED] > Sent: 04/15/2006 5:27 PM > To: REALbasic NUG > Subject: Re: Are semaphores broken? > > > > >> I believe this is because signal works on a thread level. Once you > >> call signal from a thread, in this case the main thread and no > >> other resource has a lock on your semaphore, then the signal call > >> simply returns and puts a lock that belongs to your thread on the > >> semaphore. The second time you call signal from the same thread, > >> your thread already has the lock so signal does not block and you > >> are free to continue. I think you need to test this with at least > >> one other thread to see it in action. I haven't tested > this myself > >> in a while, but I believe what I stated is correct. I'm sure > >> someone will chime in if I'm mistaken. > >> > >> Kevin > > > > > > You are describing a CriticalSection. The documentation for > > Semaphore is explicit that the counter will decrement even in the > > same thread. By inference, it's a CriticalSection that does not > > decrement a second time in the same thread. To wit, the > > documentation for Semaphore states: > > > > The Semaphore class is different from the CriticalSection > > and Mutex classes in this way: calling Signal in the same > > thread will cause the counter to decrement. > > > > The main thread (controlling the GUI) is a thread, too. So, I > > still believe my code should block. > > > > Jeff > > You are right. I read this in the Language Reference PDF and > interpreted in the wrong way. It refers to "the" lock instead of "a" > lock and is somewhat confusing in light of the rest of the > documentation. > > Call Signal to obtain a lock on a resource. When you obtain a > lock, you can use the resource without fear that another > thread will try to use it simultaneously. If the call > succeeds, this function returns immediately and you code > continues to execute. If the lock is not available, then the > thread that called this method will wait until the lock > becomes available. When the call returns, you will have the > lock, but you may have to wait until the lock becomes > available. When you are finished using the resource, call the > Release method to give it back to the Semaphore. > > > The built in Language Ref does seem to be more clear and what > you see > would appear to be a bug. > _______________________________________________ > Unsubscribe or switch delivery mode: > <http://www.realsoftware.com/support/listmanager/> > > Search the archives of this list here: > <http://support.realsoftware.com/listarchives/lists.html> > _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
