PDA

View Full Version : libThread



Dgby714
07-10-2014, 07:05 AM
Plugin for Simba (Lape only) that exports TThread and TCriticalSection.

Currently needs testing so I've denoted it as a pre-release, v2-alpha.

This requires at least Simba 1.1.0!!

Source: https://github.com/JohnPeel/libThread
Download: https://github.com/JohnPeel/libThread/releases/tag/v2-alpha

Example: https://gist.github.com/JohnPeel/39afeac6491d264a0816

CynicRus
07-10-2014, 07:26 AM
Awesome! Thats is really great work!

masterBB
07-10-2014, 03:02 PM
I am a multithread noob, but how does this compare to using the functions from Brandon? https://villavu.com/forum/showthread.php?t=108229

Olly
07-10-2014, 03:32 PM
I did export TMMLTimer also, which pretty much does achieves the same thing imo.

Turpinator
07-10-2014, 03:40 PM
Why does this thread not include a mention to Robert;?

rj
07-10-2014, 03:41 PM
Why does this thread not include a mention to Robert;?

Mentioned right when I read this Thread, pun intended

Dgby714
07-10-2014, 05:30 PM
Why does this thread not include a mention to Robert;?

Why would it?

Dgby714
07-10-2014, 05:31 PM
I am a multithread noob, but how does this compare to using the functions from Brandon? https://villavu.com/forum/showthread.php?t=108229

No clue, his has more than just threading.

I just exported TThread from FPC to Lape through a plugin.

Brandon
07-10-2014, 06:21 PM
I am a multithread noob, but how does this compare to using the functions from Brandon? https://villavu.com/forum/showthread.php?t=108229

For the Threading API itself, there isn't a different. For locking/synchronisation however:

Mutex vs. Critical Section.

Mutexes use Kernel level synchronisation whereas Critical Sections are done in Usermode.
Mutexes can be used across processes whereas Critical Sections cannot.
Critical Sections are faster than Mutexes provided that there is no thread contention. Otherwise a critical section will allocate a semaphore or mutex object automatically and will have the same performance of a mutex.
Mutexes are objects that are owned by a thread and as such, it blocks until that object itself is released. A mutex in other words is not a requirement but a warning..

For a thread can optionally ignore the mutex and access the resource anyway. The same can be done for a CriticalSection if you try. With a mutex, it's easier to ignore. That being said, if you ignore a mutex or critical section, you might as well have not coded them in, in the first place.

The TLapeThread supports termination and suspension whereas what I wrote has it "optional" provided you decide to use WinAPI to achieve it (which the TLapeThread does).

I'm not sure that it is a good idea to export those simply for the fact that if you forcefully terminate a thread or suspend it in a bad/unexpected state, it will leak resources (upon termination) and deadlock (upon suspension). For suspension & termination, you should be using an atomic variable or a a regular variable with synchronisation aka "Condition Variable": http://en.wikipedia.org/wiki/Monitor_(synchronization) or http://msdn.microsoft.com/en-ca/library/windows/desktop/ms682052(v=vs.85).aspx.


TLDR:
Other than locking mechanisms, the functions are the same. With the exception of thread forceful termination & suspension, I'd use this for threading as it's just a threading only API.

masterBB
07-10-2014, 09:46 PM
Thanks, I will look into both plugins. Just for fun of course ;)

Dgby714
07-11-2014, 06:05 AM
For the Threading API itself, there isn't a different. For locking/synchronisation however:

Mutex vs. Critical Section.

Mutexes use Kernel level synchronisation whereas Critical Sections are done in Usermode.
Mutexes can be used across processes whereas Critical Sections cannot.
Critical Sections are faster than Mutexes provided that there is no thread contention. Otherwise a critical section will allocate a semaphore or mutex object automatically and will have the same performance of a mutex.
Mutexes are objects that are owned by a thread and as such, it blocks until that object itself is released. A mutex in other words is not a requirement but a warning..

For a thread can optionally ignore the mutex and access the resource anyway. The same can be done for a CriticalSection if you try. With a mutex, it's easier to ignore. That being said, if you ignore a mutex or critical section, you might as well have not coded them in, in the first place.

The TLapeThread supports termination and suspension whereas what I wrote has it "optional" provided you decide to use WinAPI to achieve it (which the TLapeThread does).

I'm not sure that it is a good idea to export those simply for the fact that if you forcefully terminate a thread or suspend it in a bad/unexpected state, it will leak resources (upon termination) and deadlock (upon suspension). For suspension & termination, you should be using an atomic variable or a a regular variable with synchronisation aka "Condition Variable": http://en.wikipedia.org/wiki/Monitor_(synchronization) or http://msdn.microsoft.com/en-ca/library/windows/desktop/ms682052(v=vs.85).aspx.


TLDR:
Other than locking mechanisms, the functions are the same. With the exception of thread forceful termination & suspension, I'd use this for threading as it's just a threading only API.

Heh, Thanks for the clarification! So FPC's cross TThread's Terminate only supports windows?
Hmm, Didn't know that...

Haven't seen you in awhile =)

Brandon
07-11-2014, 06:44 AM
Heh, Thanks for the clarification! So FPC's cross TThread's Terminate only supports windows?
Hmm, Didn't know that...

Haven't seen you in awhile =)


Yeah I think it is only supported on Windows and mostly deprecated for Linux because of some security issues. Don't remember all the details but I'm fairly certain it uses WinAPI's "SuspendThread" & "ResumeThread" functions. I'll have to double check to be 100% sure.

Yeah. Likewise I haven't seen you as well.

EDIT: http://forum.lazarus.freepascal.org/index.php?topic=14920.0

Apparently it never worked on Linux either.. But it's very easy to roll your own so no worries. I don't think you should remove it but that's your decision to make.

It'd only be dangerous to unfamiliar developers with no WinAPI or threading background.. Other than that, I say keep it tbh. Everyone knows you shouldn't terminate a thread in a bad/unknown state but sometimes I find it necessary.

Dgby714
07-11-2014, 02:58 PM
Yeah I think it is only supported on Windows and mostly deprecated for Linux because of some security issues. Don't remember all the details but I'm fairly certain it uses WinAPI's "SuspendThread" & "ResumeThread" functions. I'll have to double check to be 100% sure.

Yeah. Likewise I haven't seen you as well.

EDIT: http://forum.lazarus.freepascal.org/index.php?topic=14920.0

Apparently it never worked on Linux either.. But it's very easy to roll your own so no worries. I don't think you should remove it but that's your decision to make.

It'd only be dangerous to unfamiliar developers with no WinAPI or threading background.. Other than that, I say keep it tbh. Everyone knows you shouldn't terminate a thread in a bad/unknown state but sometimes I find it necessary.

Ah, I see, hmmm, I should just export two properties to make it easier for people to implement their own suspending and terminating...

Dgby714
10-03-2014, 03:36 AM
Olly; broke this library with a commit to Simba, will be writing a fix and recompiling soon.

Olly
10-03-2014, 03:37 AM
Olly; broke this library with a commit to Simba, will be writing a fix and recompiling soon.

Aha, actually it was cynic. ;)

Dgby714
10-03-2014, 09:41 PM
Aha, actually it was cynic. ;)

Cynic wrote the code for PS, you exported it to Lape, you broke it...

bonsai
10-03-2014, 10:30 PM
I'm excited to try this but I'm sure I'm going to make crashes.

Clarity
10-03-2014, 10:35 PM
I am a multithread noob

Yeah, me too. I recompiled the .dll after removing the broken part and got the test script to run fine, but guess I don't think I understand the concepts enough...I tried putting in more complex things for it to do besides add stuff to the x string, and Simba crashed every run.

What exactly can you do within these threads/critical sections? Any function or procedure you want, or just simple tasks?

Like I'm trying to multithread mouse movements, color searches, or perhaps script progress report updating, stuff like that. Does this library allow for this?
I've read about safe thread management, the purposes of critical sections, but I'm having trouble applying that to Simba/Lape.

Brandon
10-04-2014, 04:08 AM
...

I couldn't get it to work :S

Gotta wait on an update I guess.. Anyway.. it should be able to run any function.. Not sure if you have to declare it native or not. You might have to do some things via "getClient().blah.blah" instead of just the regular functions.

There are many uses for threads..

Painting live is a good use I guess.. Parallel sort, parallel calculations, Asynchronous sockets, etc..

Dgby714
10-04-2014, 09:45 AM
It will crash using any of MML's methods as they are not threadsafe, but you can use MML through the Client variable.

Dgby714
12-05-2014, 04:50 AM
I've pushed a new "pre-release" on GitHub with changes to conform with current Simba exports.

Clarity
12-05-2014, 05:27 AM
I've pushed a new "pre-release" on GitHub with changes to conform with current Simba exports.
Thank you so much!