I have a loop operating on IO, and half of the work needs to be done in a 2nd thread. (I'm using pthreads.)
Is it faster to spawn a new thread (and then join it) with each iteration of my loop? Or is it faster to spawn a 2nd thread a single time and put the 2nd thread in a loop as well and use a semaphore to control it? (I.e. first thread posts to the semaphore, and the 2nd thread waits on the semaphore.)
I'm working with C code on an Android tablet.
Related
Is the thread in MS Windows with C++ a time slice or the execution of a function or both?
A thread is executing a function which is a block of code inside an outer loop. If you send a signal (via a global variable) to break from the outer loop. The function returns, but what happens to the running thread assuming it is a time slice of execution?
Neither.
If your scheduler is set to a time-slice algorithm then the time-slice represents when and how long your thread will run.
A thread is an object that manages a block of executable code that can be scheduled. Typically, as part of thread creation you pass a function pointer to that block of code. When the "job" of the executable code is done the thread is destroyed.
In 32-bit and 64-bit Windows, every thread runs a specified function. Conceptually speaking, the initial thread of a new process runs the application's main function, and every additional thread runs a function specified by the programmer when the thread is created. See the documentation for CreateThread; the lpStartAddress argument specifies the function for the thread to run.
(In fact, each thread also runs operating system code, and usually runtime library code as well, but that's an implementation detail that doesn't matter for our purposes.)
Conceptually, when any particular thread is running on a particular CPU core, it might stop for either of two reasons: because the thread has stopped running altogether, or because of a context switch. In the case of a context switch, the thread will be started up again at a later time, and from the thread's point of view everything will look the same as it did when it was interrupted.
(In fact, the OS may also interrupt the thread in order to run device driver or other operating system code. This doesn't involve a context switch; the device driver code runs in the context of the interrupted thread, which is one of the reasons device drivers are hard to write.)
Here are some of the reasons the thread might stop running altogether ["exit"]:
The function the thread was created to run has exited.
The thread calls ExitThread().
Some other thread calls TerminateThread().
Here are some of the reasons there might be a context switch:
The thread's timeslice has expired.
Another thread with a higher priority has become ready to run.
The thread calls Sleep() or one of the wait functions.
It's hard to tell what you're trying to ask, so this may not have addressed it. But perhaps it will clarify things enough to allow you to ask your question in words I can understand.
What I would like to do is to have one thread waiting for messages (WaitMessage) and another processing the logic of the application. The first thread would wake up on every message, signal somehow this event to the other thread, go to sleep again, etc. Is this possible?
UPDATE
Consider the following situation. We have a GUI thread, and this thread is busy in a long calculation. If there is no other thread, there is no option but to check for new messages from time to time. Otherwise, the GUI would become irresponsive during the long calculation. Right now my system uses this "polling" approach (it has a single thread that checks the message queue from time to time.) However, I would like to know whether this other solution is possible: Have another thread waiting on the OS message queue of the GUI so that when a Windows message arrives this thread will wake up and tell the other about the message. Note that I'm not asking how to communicate the news between threads but whether it is possible for the second thread to wait for OS messages that arrive in the queue of the first thread.
I should also add that I cannot have two different threads, one for the GUI and another for the calculations, because the system I'm working on is a Virtual Machine on top of which runs a Smalltalk image that is not thread safe. That's why having a thread that only signals new OS messages would be the ideal solution (if possible.)
This depends on what the second thread needs to do once the first thread has received a message.
If the second thread simply needs to know the first thread received a message, the first thread could signal an Event object using SetEvent() or PulseEvent(), and the second thread could wait on that event using WaitForSingleObject().
If the second thread needs data from the first thread, it could use an I/O Completion Port. The first thread could wrap the data inside a dynamically allocated struct and post it to the port using PostQueuedCompletionStatus(), and the second thread could wait for the data using GetQueuedCompletionStatus() and then free it when done using it.
Update: based on new information you have provided, it is not possible for one thread to wait on or service another thread's message queue. Only the thread that created and owns the queue can poll messages from its queue. Each thread has its own message queue.
You really need to move your long calculations to a different thread, they don't belong in the GUI thread to begin with. Let the GUI thread manage the GUI and service messages, do any long-running things in another thread.
If you can't do that because your chosen library is not thread safe, then you have 4 options:
find a different library that is thread safe.
have the calculations poll the message queue periodically when running in the GUI thread.
break up the calculations into small chunks that can be triggered by the GUI thread posting messages to itself. Post a message and return to the message loop. When the message is received, do a little bit of work, post the next message, and return to the message loop. Repeat as needed until the work is done. This allows the GUI thread to continue servicing the message queue in between each calculation step.
move the library to a separate process that communicates back with your main app as needed.
In Linux multi-threading (pthread), I want to asynchronously
suspend a thread while its performing a system call.
Imagine that there is a system call consisted with 100 assembly lines.
I want a thread to pause its execution inside kernel(syscall) at some
specific range of assembly codes(say, somewhere between line 20 ~ line 50). and later resume the thread from there(syscall instruction) whenever I want.
This doesn't have to be reliable. If I have to try suspending - resuming the thread 10000 times and only one trial gives me what I want, its fine.
Can I use signals to achieve what I want?
I think signals will not be asynchronously handled when the target thread is inside kernel...
it would be really nice if I could get some advice about this issue.
thank you in advance.
i'm not sure about something.
when i use critical_section/mutex/semaphor in c++ for example , how does the busy_wait problem being prevented ?
what i mean is when a thread reaches a critical section and the critical section is occupied by other thread, what prevents the thread from wasting cycle time and wait for nothing ?
for example,
should i call TryEnterCriticalSection and check if the thread obtained ownership and otherwise call sleep(0) ?
i'm a bit perplexed
thanks
This is Windows specific, but Linux will be similar.
Windows has the concept of a ready queue of threads. These are threads that are ready to run, and will be run at some point on an available processor. Which threads are selected to run immediately is a bit complicated - threads can have different priorities, their priorities can be temporarily boosted, etc.
When a thread waits on a synchronization primitive like a CRITICAL_SECTION or mutex, it is not placed on the ready queue - Windows will not even attempt to run the thread and will run other threads if possible. At some point the thread will be moved back to the ready queue, for instance when the thread owning the CS or mutex releases it.
The thread is not going to be taking any system resources, because it will be marked as "waiting". As soon as the thread occupying the critical region finishes, it will send out a signal that will move the waiting thread to the ready queue.
These control structures stop the thread that can't enter from doing a busy wait by allowing it to sleep until an interrupt is generated by the thread that is in the critical section finishing execution. Because the thread is asleep it is not using processor cycles, so no busy_wait.
I've read the documentation for ReadDirectoryChangesW() and also seen the CDirectoryChangeWatcher project, but neither say why one would want to call it asynchronously. I understand that the current thread will not block, but, at least for the CDirectoryChangeWatcher code that uses a completion port, when it calls GetQueuedCompletionStatus(), that thread blocks anyway (if there are no changes).
So if I call ReadDirectoryChangesW() synchronously in a separate thread in the first place that I don't care if it blocks, why would I ever want to call ReadDirectoryChangesW() asynchronously?
When you call it asynchronously, you have more control over which thread does the waiting. It also allows you to have a single thread wait for multiple things, such as a directory change, an event, and a message. Finally, even if you're doing the waiting in the same thread that set up the watch in the first place, it gives you control over how long you're willing to wait. GetQueuedCompletionStatus has a timeout parameter that ReadDirectoryChangesW doesn't offer by itself.
You would call ReadDirectoryChangesW such that it returns its results asynchronously if you ever needed the calling thread to not block. A tautology, but the truth.
Candidates for such threads: the UI thread & any thread that is solely responsible for servicing a number of resources (Sockets, any sort of IPC, independent files, etc.).
Not being familiar with the project, I'd guess the CDirectoryChangeWatcher doesn't care if its worker thread blocks. Generally, that's the nature of worker threads.
I tried using ReadDirectoryChanges in a worker thread synchronously, and guess what, it blocked so that the thread wouldn't exit by itself at the program exit.
So if you don't want to use evil things like TerminateThread, you should use asynchronous calls.