I have the following scenario:
Run thread group a once at setup
Run a separate thread group b once at setup
Repeatedly loop requests in thread group c.
make all those threads that participated in groups b and c run thread group d
Make the thread that participated in thread group a run thread group e
How do I do this? It's number 1 and 5 that I'm not sure about, and how to make sure threads from a don't participate in c.
JMeter threads (virtual users) cannot go outside the Thread Group, once started, a thread executes Samplers upside down (or according to the Logic Controllers). When a thread doesn't have more Samplers to execute or loops to iterate - it's being shut down.
Threads are not going to the next Thread Group.
If you need to "pass" a thread from one thread group to another the only way of doing this is starting a brand new thread in another Thread Group and pass the "context" of the thread from the first Thread Group to the new thread, it may include:
JMeter Variables
Headers
Cookies
etc.
There are 2 approaches of passing the data between threads in different thread groups:
Convert the data you want to pass into JMeter Properties using __setProperty() function in the first Thread Group so set the value(s) and __P() function in the second Thread Group to read the value(s)
Using Inter-Thread Communication Plugin
There was a simple way to do this. Add a throughput controller in the same setUp group b. Make total throughput executions = 1. Done.
Related
I want to run the login thread group always first and wait for it to finish. And then in the same test plan run other thread group in parallel.
e.g.
Login-1 (always first )
Thread group-2 (after login in parallel)
Thread group-3 (after login in parallel)
Take a look at setUp Thread Group, as per description:
A special type of ThreadGroup that can be utilized to perform Pre-Test Actions. The behavior of these threads is exactly like a normal Thread Group element. The difference is that these type of threads execute before the test proceeds to the executing of regular Thread Groups.
More information: How to Use the SetUp Thread Group in JMeter
Below Test plan might help you.
Here first thread group is a setUP Thread Group which will be executed once, Rest are regular thread groups.
(You can run setUp Thread group with as many number of users and duration you want, other Regular Thread groups will wait until setup thread is completed)
On test plan level uncheck "Run Thread Groups consecutively"
I am trying to understand the concept behind the threadpool. Based on my understanding, a thread can not be restarted once completed. One will have to create a new thread in order to execute a new task. If that is the right understanding, does ThreadPool executor recreates new thread for every task that is added?
One will have to create a new thread in order to execute a new task
No. Task are an abstraction of a logical work to perform. It can be typically a function reference/pointer with an ordered list of well-defined parameters (to give to the function). Multiple tasks can be assigned to a given thread. A thread pool is usually a set of threads waiting for new incoming tasks to be executed.
As a result, threads of a given thread-pool are created once.
I'm trying to create a semaphore for multiple threads, i need to run only one thread at a time. I'm declaring the semaphore in my dialog file
ghSemaphore = CreateSemaphore(NULL, 1, 1, NULL); // only one thread at once
Before i start the tread i call
WaitForSingleObject(ghSemaphore, 0L);
Before the thread ends i call:
ReleaseSemaphore(ghSemaphore, 1, NULL);
It starts all treads instead of one tread once. Any idea please ?
Thanks a lot!
You say "before i start the thread..(you acquire the semaphore)" - so always in the same (main) thread?
I think, the semaphore restrict its acquisition to only one thread (which here would be the main thread), so the acquisition needed to be placed inside the (child) threads, to only allow one of them to run concurrently.
You have to create the single one semaphore in the parent thread and pass a reference to it to the child threads. Once one child thread is released from Wait..() the semaphore blocks concurrent threads until the first one releases the semaphore and some next child thread is allowed to run. However, all child threads do run concurrently until their call of the Wait..().
Btw: Why do you create multiple threads if you actually want only one thread to run at any time (until it terminates)?
Regarding the scope where to create the semaphore: From the info you provided it looks ok to have one single semaphore at application level. However, i would recommend to pass it to the child threads as a parameter at thread start (instead of referring a global variable), so the child threads are independent of the choice of the scope. If you ever need to handle multiple, independent bunches of such child threads, you can easily switch to create one semaphore for each bunch just before they are created (the other option you mentioned). If you create semaphores on the fly, be sure to release it, once all threads have terminated.
So, for now, best create one application-wide semaphore ("global").
I am trying to implement a parallel version of 'Game Of Life'.
This parallel version divides the game's board into regions, each governed by a single thread which is responsible of calculating this region's next state and conduct the state update afterwards.
One of the constraints I am facing here is the fact that - "Each thread is allowed to access only its own region cells. All other information should be communicated from the neighboring threads by some other memory".
So, the way I understand this, even if one thread attempts to read only from a cell outside it's region, it must somehow request this state from the specific thread which is running this cell.
We are encouraged to consider the producer/consumer solution for this task, and so I have considered using a public static produce/consumer queue into which state requests shall be enqueued, but some other related issues are not clear to me:
If thread A is conducting a job at the moment, how can I ask it to halt it's work and hand thread B it's information request and resume it's previous job afterwards? Is it even possible?
Which thread is responsible for this queue? a unique thread which manages the queue in parallel to the regular regions threads? I am not sure.
The easiest solution is to imagine there are multiple steps in each round.
Let's say there are N threads.
step 1: each thread makes a list of cells it needs to discover. It puts the "question" in one of the N queues that there are (one for each thread).
wait for all the threads to finish
step 2: each thread fill the responses for its queue of question
wait for all the threads to finish
step 3: each thread computes the new state of its region
wait for all the threads to finish
I'm new to Multithread in Win32. And I have an assignment with Semaphore. But I cannot understand this.
Assume that we have 20 tasks (each task is the same with other tasks). We use semaphore then there's 2 circumstances:
First, there should be have 20 childthreads in order that each thread will handle 1 task.
Or:
Second, there would be have n childthreads. When a thread finishs a task, it will handle another task?
The second problem I counter that I cannot find any samples for Semaphore in Win32(API) but Consonle that I found in MSDN.
Can you help me with the "20 task" and tell me the instruction of writing a Semaphore in WinAPI application (Where should I place CreateSemaphore() function ...)?
Your suggestion will be appreciated.
You can start a thread for every task, which is a common approach, or you can use a "threadpool" where threads are reused. This is up to you. In both scenarios, you may or may not use a semaphore, the difference is only how you start the multiple threads.
Now, concerning your question where to place the CreateSemaphore() function, you should call that before starting any further threads. The reason is that these threads need to access the semaphore, but they can't do that if it doesn't exist yet. You could of course pass it to the other threads, but that again would give you the problem how to pass it safely without any race conditions, which is something that semaphores and other synchronization primitives are there to avoid. In other words, you would only complicate things by creating a chicken-and-egg problem.
Note that if this doesn't help you any further, you should perhaps provide more info. What are the goals? What have you done yourself so far? Any related questions here that you read but that didn't fully present answers to your problem?
Well, if you are contrained to using semaphores only, you could use two semaphores to create an unbounded producer-consumer queue class that you could use to implement a thread pool.
You need a 'SimpleQueue' class for task objects. I assume you either have one already, can easily build one or whatever.
In the ctor of your 'ProducerConsumerQueue' class, (or in main(), or in some factory function that returns a *ProducerConsumerQueue struct, whatever your language has), create a SimpleClass and two semaphores. A 'QueueCount' semaphore, initialized with a count of 0, and a 'QueueAccess' semaphore, initialized with a count of 1.
Add 'push(*task)' and ' *task pop()' methods/memberFunctions/methods to the ProducerConsumerQueue:
In 'push', first call 'WaitForSingleObject()' API on QueueAccess, then push the *task onto the SimpleQueue, then ReleaseSemaphore() API on QueueAccess. This pushes the *task in a thread-safe manner. Then ReleaseSemaphore() on QueueCount - this will signal any waiting threads.
In pop(), first call 'WaitForSingleObject()' API on QueueCount - this ensures that any calling consumer thread has to wait until there is a *task in the queue. Then call 'WaitForSingleObject()' API on QueueAccess, then pop task from the SimpleQueue, then ReleaseSemaphore() API on QueueAccess and return the task - this this thread-safely dequeues the *task.
Once you have created your ProducerConsumerQueue, create some threads to run the tasks. In CreateThread(), pass the same *ProducerConsumerQueue as the 'auxiliary' *void parameter.
In the thread function, cast the *void back to *ProducerConsumerQueue and then just loop around for ever, calling pop() and then running the returned task.
OK, your pool of threads is now ready to do stuff. If you want to run 20 tasks, create them in a loop and push them onto the ProducerConsumerQueue. The threads will then run them all.
You can create as many threads as you want to in the pool, (within reason). As many threads as cores is reasonable for tasks that are CPU-intensive. If the tasks make blocking calls, you may want to create many more threads for quickest overall throughput.
A useful enhancement is to check for 'null' in the thread function loop after each task is received and, if it is null, clean up an exit the thread, so terminating it. This allows the threads to be easily terminated by queueing up nulls, making it easier to shutdown your thread pool, (should you need to), and also to control the number of threads in the pool at runtime.