i have gotten some pretty strange results using the PB debugger... In fact, in some strange circumstances, the debugger actually prints out the name of a mutex as it's created... which is odd since there isn't a single debugger command in my lib!?
I do also know that the debugger affects syncronization (because it uses thread-safe API calls perhapse?)
I'll run my demo now and try to see what you're talking about... how long does it take for a thread to lock up?
You are right that when using the debugger and running threads there is often a mix between what is displayed and variables contents.
I noticed that also.
Rgrds
My avatar is a small copy of the 4x1.8m image I created and exposed at 'Le salon international du meuble à Paris' january 2004 in Matt Sindall's 'Shades' designers exhibition. The original laminated print was designed using a 150 dpi printout.
I'm trying to wait for a thread to change a certain variable... using this OpenThreadResource() / Close...() .... but the value is never changing - even though the thread DOES change it.
It creates a thread resource (which is probably either a semaphore or mutex). You need to use it before you can use openthreadresource(), otherwise you won't have a resource to open :)
@PolyVector: does anyone get emails sent to support@skunksoft.com? Just wondering because I sent one 6 days ago and never got any response. Perhaps my email wasn't worth responding to of course :)
edit: typos :)
Last edited by tinman on Mon Jul 05, 2004 1:05 am, edited 1 time in total.
If you paint your butt blue and glue the hole shut you just themed your ass but lost the functionality.
(WinXPhSP3 PB5.20b14)
Ok.... I did use it as per the example that comes with the library...
just that it doesn't explain what is a resource... or why you'd create more than one. It doesn't take any parameters - just returns a handle to a resource..... which you then call OpenThreadResource() with.....
Can you give me a more specific idea of what's going on? (puzzled!)
A resource in the Skunksoft ThreadSync library seems to be either a sempahore or mutex (I'll just call them resources from now on), which at an OS level is an entity/object/thing/whatever that can be used to synchronise threads. It works because all functions which operate on said resource go through the OS and allows only one function call to operate on the resource at any one time.
A resource can generally be in one of two states - available or unavailable. They become unavailable (meaning that thread has exclusive access to the resource) by you calling OpenThreadResource() and available (no thread has exclusive access) by calling CloseThreadResource(). In the SS_TS library case, if a thread has access to a resource (i.e. it has called OpenThreadResource()) then it will be the only thread which has access to the resource (due to the OS controlling the access by functions).
This means that you can use a resource to control access to a shared item of any other type. For example, lists, arrays or global variables. But you must always make sure that any access to such a shared item is controlled by a resource. If you have access to the resource (remember, only one thread at a time) than you know that it is safe to use the shared item.
You would need one resource for each shared item that is accessed separately, otherwise you cannot control which threads have access to it.
If you paint your butt blue and glue the hole shut you just themed your ass but lost the functionality.
(WinXPhSP3 PB5.20b14)
Ok, I understand the explanation.... that all makes sense.
Except... how do I connect a 'resource' with the object in question.
In my case I'm doing this.....
Procedure thread()
;process a thread message....
messageProcessed = 1
EndProcedure
...main app...
messageProcessed = 0
SendThreadMessage()
Repeat
Delay(xx)
Until messageProcessed = 1
..... this is to wait for the thread to finish processing the message...
why don't I use SendThreadMessageAndWait() ?
because I set up a load of message parameters that are global variables.... it seem that the SendThreadMessageAndWait() just waits for the message to be retrieved from the queue.... that then screws up my next message since it can be sent before the current one has finished processing.
So I wrapped up all access to the variable 'messageProcessed' within OpenThreadResource() / CloseThreadResource() calls... and used that to signal when the message is done....
but my problem is that the Repeat / Until loop never detects that messageProcessed = 1
Well it sounds like you've done it right (wrapping all accesses to messageProcessed with a resource). I guess you have a "Global messageProcessed" in the main code, or a "Shared messageProcessed" in the thread procedure, otherwise they will be accessing different variables.
The other thing would be that you'd need to make sure you wrap the accesses correctly. There's no point putting a OpenThreadResource() before the "Until" line and a CloseThreadResource() call after it, because you would probably get access to it, but never release it causing a deadlock. Best to use something like:
@tinman
I recieved an email about the ThreadSync lib about a week ago and replied the same day... If that message was from you, then perhapse your email server blocks Global.com addresses?
@BrendanE
A ThreadResource is a mutex... Maybe you would gain a better understanding of what's going on using the mutex commands directly... I learned everything I needed to know from the MSDN site
@PolyVector:
Thanks. Either that or I was probably over-zealous in deleting my daily dose of spam. Would you be able to send your reply again please? Sorry for the hassle.
If you paint your butt blue and glue the hole shut you just themed your ass but lost the functionality.
(WinXPhSP3 PB5.20b14)
PolyVector wrote:I re-sent it... I hope it works this time :)
Thanks, I've got your reply now. Not exactly what I wanted to hear though as I discontinued my own ThreadSync library in favour of the simpler and more complete (well, it had message passing :) of your library.
If you paint your butt blue and glue the hole shut you just themed your ass but lost the functionality.
(WinXPhSP3 PB5.20b14)