How does semaphore work in Qt c++?
when looking to the semaphore example I see that we pass the size of buffer that
we want the semaphore to control not the address of our resource (e.g. QList)
so how does it know that it is this QList or the other one or the QMap defined earlier?
I am newbie to semaphore and I cant understand the underlying structure..
Related
The threadblocking of a semaphore or a mutex often causes program stuttering, and I'd rather have one that was based on QEventLoop, where as that will not halt the thread.
Does this already exist, particularly for a semaphore, or do I need to create my own class to implement this?
Thanks.
Let me quickly explain what I'm trying to do. I currently have a program consisting of 2 threads. One worker thread and one GUI thread, the worker thread is collecting sensor data at 2kHz and the GUI thread visualize the collected data. The program is written in c++ using the Qt framework.
I have already tried the signal and slot option, I did this by passing a Qvector<PointF> as a signal in my worker thread to a slot in my GUI thread. But then I had a problem with "choppy data", while the data was being plotted my worker was stopped.
I then thought of using a singleton to pass data between the two threads, and here comes the main question; is using a singleton a good solution in this case? Or is there a better way to solve the problem?
I have already tested the concept by using a global Qvector<PointF> and a global mutex to protect the data but as global variables are frowned upon I thought of using a singleton instead.
Best regards
No, that is not what singletons were meant for. You have two threads, just provide a shared mechanism for moving data from one to the other, and make that mechanism available to both threads.
i am newbie in C++ and boost.
As part of my master thesis, i wrote a program which simulate a statistical model. During the computation, i use boost::thread to process my "center of mass vector", for saving some computation time. So far so good.
Now, i would like to take each result from the boost::thread (each time one element) and pass it to a running thread, which is going to preform recursive regression.
My questions:
how can i pass my new computed element to the existing thread?
how could i "wake-up" the thread, when i pass the new element?
i would be happy if someone could point me to an existing example.
the simplest possible way is to use std::queue, boost::mutex and boost::conditional_variable. wrap any access to queue by mutex, after pushing to queue call conditional_variable.notify_one(). in consumer thread wait on conditional_variable until any result is ready, then process it.
A proven way to control a thread from another thread is to send messages via a combination of a queue with a conditional variable. Unfortunately, boost::thread doesn't provide a standard solution and there are a couple of tricky things when implementing (possible deadlocks, behaviour when queue is full, use polymorphic messages...)
You should use mutex and/ro semaphore to synchronize your threads and lock variable to achieve thread-safe communication. Just note that all threads in your process share the same memory so you can access the same data, but you have to do it in a thread-safe way.
I'm not sure if boost library implements any threading primitives, but here is a good tutorial about multi-threading programming using POSIX threads - http://www.yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html
I've been using the Semaphore class to create semaphores. However, the examples use managed code (requires /clr), and I need to use unmanaged code because it seems FreeType doesn't like working with managed code.
How can I create two simple threads which use a semaphore in unmanaged code?
Use native Windows semaphore objects.
You may try and use Boost.interprocess. It provides semaphores. See here.
You want CreateSemaphore which is implemented in kernel32. The general pattern is to create a name or unnamed semaphore object to use from both threads. You can use OpenSemaphore to get a handle to an existing named semaphore. Set the initial count and maximum counts on your semaphore appropriately then use one of the Wait Functions to take a logical lock on your shared resource by decrementing the count on your semaphore. When your thread has finished with the resource, call ReleaseSemaphore to increment the available lock count.
I have a main process that uses a single thread library and I can only the library functions from the main process. I have a thread spawned by the parent process that puts info it receives from the network into a queue.
I need to able to tell the main process that something is on the queue. Then it can access the queue and process the objects. The thread cannot process those objects because the library can only be called by one process.
I guess I need to use pipes and signals. I also read from various newsgroups that I need to use a 'self-trick' pipe.
How should this scenario be implemented?
A more specific case of the following post:
How can unix pipes be used between main process and thread?
Why not use a simple FIFO (named pipe)? The main process will automatically block until it can read something.
If it shouldn't block, it must be possible to poll instead, but maybe it will suck CPU. There probably exists an efficient library for this purpose.
I wouldn't recommend using signals because they are easy to get wrong. If you want to use them anyway, the easiest way I've found is:
Mask all signals in every thread,
A special thread handles signals with sigwait(). It may have to wake up another thread which will handle the signal, e.g. using condition variables.
The advantage is that you don't have to worry anymore about which function is safe to call from the handler.
The "optimal" solution depends quite a bit on your concrete setup. Do you have one process with a main thread and a child thread or do you have one parent process and a child process? Which OS and which thread library do you use?
The reason for the last question is that the current C++03 standard has no notion of a 'thread'. This means in particular that whatever solution your OS and your thread library offer are platform specific. The most portable solutions will only hide these specifics from you in their implementation.
In particular, C++ has no notion of threads in its memory model, nor does it have a notion of atomic operations, synchronization, ordered memory accesses, race conditions etc.
Chances are, however, that whatever library you are using already provides a solution for your problem on your platform.
I highly suggest you used a thread-safe queue such as this one (article and source code). I have personally used it and it's very simple to use. The API consist in simple methods such as push(), try_pop(), wait_and_pop() and empty().
Note that it is based on Boost.Thread.