Page 1 of 3
Skunksoft ThreadSync Lib 1.0
Posted: Mon May 03, 2004 9:19 am
by PolyVector
Hello everyone,
I've just updated our SS_ThreadSync lib... It comes with a PB userlib version, and two DLL versions for use in other languages.... It has some handy new features:
- Maintains thread saftey in your programs
- Allows for messages to easily be sent to and from threads.
- Supports waiting on incomming/outgoing messages w/ little to no CPU usage.
- Easy to insert into existing, thread-retarded, programs...
Download Here:
http://www.skunksoft.com/Downloads/SS_ThreadSync.zip
Please post any bugs on our forums...
http://www.skunksoft.com/forums/
Oh, and again... The site's a complete mess right now, I know...
Posted: Mon May 03, 2004 1:01 pm
by Karbon
Awesome work. I will be taking a look ASAP!
Posted: Thu May 06, 2004 6:53 pm
by thefool
thanks!
Good work
Anyway, this is taken from the readme.txt file:
"It also works as a coaster when burned on a CD..."
I burned it on a cd and it didnt work as a coarster. I even tried to burry
it in the garden and waited several minutes, and it didnt become a coaster
once again like karbon said, "Awesome work"
Posted: Thu May 06, 2004 7:16 pm
by PolyVector
Thanks guys, I was beginning to think that's all it was getting used for
Tell me how it works out in your projects!
Posted: Fri May 07, 2004 4:17 pm
by Num3
What the heck is a coaster :roll:
Posted: Fri May 07, 2004 4:31 pm
by blueznl
berikco! tell the guy what a bierviltje is, the barbarian!
Posted: Fri May 07, 2004 8:12 pm
by PolyVector
A coaster keeps stains off your coffee table, and crappy software off your computer
Posted: Fri May 07, 2004 11:10 pm
by thefool
why didnt you tell that before? I thought it was a roller-coaster and burried it in the garden to watch it grow
Posted: Fri May 07, 2004 11:33 pm
by PolyVector
Windows IS a roller-coaster
Posted: Fri May 07, 2004 11:34 pm
by thefool
Posted: Sun May 16, 2004 9:29 am
by spongehammer
I wonder if i am missing something here (wouldnt be the first time
)
The lib demo supplied should show the variables being added in on thread and subtracted in the other. Watching the debugger this seems to be the case. However its not long before one or the other threads just seems to stop responding, leading to just addition or just subtraction.
Before looking at this lib i had been trying to get 2 threads to send messages to each other, and have found that they seem to act the same way.. work for a while then one of them stops. I tried inserting delays which seemed to work to some degree. I had high hopes for this lib sorting my problems out.
Any ideas anyone ?
Chris
Posted: Sun May 16, 2004 10:31 am
by spongehammer
I wonder if it's the debugger which is giving the odd results,
i tried this simple prog running from pb and watching the debugger output..
Code: Select all
Global variable.l
Procedure addme()
Repeat
variable+1
;Debug "Addme Working"
Delay(10)
ForEver
EndProcedure
Procedure subme()
Repeat
variable-1
;Debug "Subme Working"
Delay(10)
ForEver
EndProcedure
CreateThread(@addme(),0)
CreateThread(@subme(),0)
Repeat
Debug variable
Delay(1)
ForEver
Then i tried this code, which seems just as bad (as you would expect)
Code: Select all
Enumeration
#Window_0
EndEnumeration
Enumeration
#String_0
EndEnumeration
Global variable.l
Procedure addme()
Repeat
variable+1
;Debug "Addme Working"
Delay(10)
ForEver
EndProcedure
Procedure subme()
Repeat
variable-1
;Debug "Subme Working"
Delay(10)
ForEver
EndProcedure
CreateThread(@addme(),0)
CreateThread(@subme(),0)
; Repeat
; Debug variable
; Delay(1)
; ForEver
If OpenWindow(#Window_0, 558, 298, 177, 121, #PB_Window_SystemMenu | #PB_Window_TitleBar , "New window ( 0 )")
If CreateGadgetList(WindowID())
StringGadget(#String_0, 26, 29, 132, 27, "")
EndIf
EndIf
Repeat
Event = WaitWindowEvent()
SetGadgetText(#String_0,Str(variable))
Delay(10)
Until Event = #PB_EventCloseWindow
End
However when compiled and run as an .exe it does seem to be more stable.
Posted: Sun May 16, 2004 10:41 am
by fweil
spongehammer,
Just some comments. I will not go deep, but as starting the discussion :
Your first code you have just sent above renders results that will depend on the delay adjustments of each part of the code :
ie :
Code: Select all
Global variable.l
Procedure addme()
Repeat
variable+1
;Debug "Addme Working"
Delay(50)
ForEver
EndProcedure
Procedure subme()
Repeat
variable-1
;Debug "Subme Working"
Delay(10)
ForEver
EndProcedure
CreateThread(@addme(),0)
CreateThread(@subme(),0)
Repeat
Debug variable
Delay(250)
ForEver
... renders different results than the one you sent, just by changing delays.
And this is the same for the other code. By changing the delay value in addme or subme you will see that the global variable increases or decreases.
So it significates that you have to take care of what you mean or intent to do when coding.
Posted: Sun May 16, 2004 6:15 pm
by spongehammer
Hi fweil,
yes i realise this. My main concern is whether one of the threads actually stops or only seems to (according to the debugger)
Chris
Posted: Sun May 16, 2004 7:56 pm
by fweil
The point is that when a thread runs, it is 'independantly' from the caller and other running apps, and you cannot control exactly where it is except to know if it has a runtime changing AFAIK.
Also threads are priority level depending, so that if you run many, the become concurrents from the CPU point of view and they have to compete to find a thread place in the queue.
Most of the time that threads become tricky on an application, it occurs that a given thread is waiting for something that another can't send because the first is eating the whole remaining time to wait for the second ...
And this is the same between a thread and the caller.