[3] Fast multi-threaded synchronization constructs

Post your FreeBASIC source, examples, tips and tricks here. Please don’t post code without including an explanation.
Post Reply
1000101
Posts: 2556
Joined: Jun 13, 2005 23:14
Location: SK, Canada

[3] Fast multi-threaded synchronization constructs

Post by 1000101 »

Code Provided:
Reader-Writer Locks
Tagged FIFO Queue
Thread Pooler


-----
Reader-Writer Locks

A read-write lock mechanism (many reader, one writer) which allows multiple threads to read the same resource but only one thread can actively write. When a reader acquires the lock is enters a critical section, increments the reader count and leaves the critical section. The release of a reader is done the same (enter, decrement, leave). This means that readers will only block each other long enough to increment and decrement the counter. The write lock invokes a mutex and blocks all future locks from being acquired until released. Typical use of rwlocks is for one thread to process data and multiple threads to read data, eg loading (writer) and rendering (reader) graphics, updating large data sets, etc.

Note: rwLock is win32 only. Linux has native rwlock constructs and thus is not needed.


-----
Tagged FIFO Queue

The tagged FIFO queue is a non-locking construct which will enqueue a new entry at the tail and dequeue from the head. Typical usage of a FIFO queue is for multiple threads to enqueue data and a single thread to dequeue and process data, eg sending network packets, updating databases, etc.

Note: Tagged Queues require an x86 processor which supports the cmpxchg8b instruction (P5, 1993) and will work under any x86 OS.


-----
Thread Pooler

The thread pooler keeps a small collection of threads ready to be assigned asynchronous functions. The pool works the in the same way as using the ThreadCreate and ThreadCall functions but is faster to assign and begin processing a function. Additionally, the internal queue is tagged and functions an be superseded if a new function is assigned with the same tag (assuming the function hasn't need assigned to a thread yet). The pooler can optinally do a shadow copy of the data to be passed to a thread and internally manages each threads shadow so that it is not deallocated until the pooler is exited. This means that the a larger shadow allocation will reallocate a threads shadow and keep reusing it (only copying the data).


-----
Files:
rwLock: rwlock.zip
tQueue: tqueue.7z
ThreadPool: threadpool.7z
Last edited by 1000101 on Jun 09, 2012 6:06, edited 2 times in total.
Gonzo
Posts: 722
Joined: Dec 11, 2005 22:46

Re: [3] Fast multi-threaded synchronization constructs

Post by Gonzo »

cool stuff :) i prefer my buggy lock-free round-robins though :P

for example, an opengl example:
thread B: starts a job, 0-->1
thread A: compiles a job, 1-->2 job is finished
thread B: find job at state 0, and 0-->1

as you can see it only works with dual-threading, since the fetching part would require a mutex, if not "a number is assigned a thread"
lock-free round-robins work well with arrays of types / structs
you dont have to lock an entire struct to work with it!

when you have opengl, usually the driver takes up 1-2 threads, and thus, dualthreading is the best solution
if you have intel dualcore, you will have 4 threads, or like me 8 :S
however you should accomodate for only 4 threads, since that is the lowest common today
Kot
Posts: 336
Joined: Dec 28, 2006 10:34

Re: [3] Fast multi-threaded synchronization constructs

Post by Kot »

tQueue.7z and ThreadPool sent me to http://windsorportal.com/404.php, no download :(
1000101
Posts: 2556
Joined: Jun 13, 2005 23:14
Location: SK, Canada

Re: [3] Fast multi-threaded synchronization constructs

Post by 1000101 »

Kot wrote:tQueue.7z and ThreadPool sent me to http://windsorportal.com/404.php, no download :(

whoops, server changed the filename cases and didn't like the original CamelCase. Fixed now.
Post Reply