Skunksoft ThreadSync Lib 1.0

[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...

[Karbon]

Awesome work. I will be taking a look ASAP!

[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"

[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!

[Num3]

What the heck is a coaster :roll:

[blueznl]

berikco! tell the guy what a bierviltje is, the barbarian!

[PolyVector]

A coaster keeps stains off your coffee table, and crappy software off your computer

[thefool]

why didnt you tell that before? I thought it was a roller-coaster and burried it in the garden to watch it grow

[PolyVector]

Windows IS a roller-coaster

[thefool]

[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

[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.

[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.

[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

[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.