As I understand from docs yield() function is passing control to another fiber.
What will happen if we will not call yield in fiber in D? Will it's mean that thread will hang?
Or I am wrong understand that fibers works inside threads and they work inside process? And process can have or threads or fibers?
To answer this question, it is important to understand how fibers work. When you call Fiber.call() method, current execution context (CPU register state) gets dumped into memory and execution context for that fiber object is loaded instead. When you call Fiber.yield() current execution context is dumped too, but control is passed to whoever called current fiber last time. It can be both another fiber or plain thread context - it doesn't need to know as any execution context is completely defined by dumped data, it doesn't even need to be fiber aware.
When fiber function ends, it simply returns control to last caller similar to as if there was an yield call in the very end. Main difference is that when fiber function ends, matching fiber object gets into "terminated" state and on yielding it always remains in "running" state (even if there is no more to run technically). That is important because it is only defined behavior to reset and recycle fibers in terminated state.
Common mistake is to treat fibers as some sort of tasks and expect inherent scheduling semantics. It is not the case - fiber itself is simply a context switching primitive to implement any smart task system on top, there is never any scheduling on its own.
Some code example to show relevant semantics:
void main ( )
{
import core.thread, std.stdio;
Fiber fiber1, fiber2;
fiber1 = new Fiber({
fiber2.call();
Fiber.yield();
});
fiber2 = new Fiber({
Fiber.yield();
});
fiber1.call(); // switches to fiber1, which switches to fiber2
// which yield back to fiber1 and finally fiber1 yield back to main
assert (fiber1.state == Fiber.State.HOLD && fiber2.state == Fiber.State.HOLD);
fiber2.call(); // switches to fiber2 which reaches end of function
// and switches back to main upon exit
assert (fiber1.state == Fiber.State.HOLD && fiber2.state == Fiber.State.TERM);
fiber1.call(); // switches to fiber1 which also reaches end of function
// and switches back to main upon exist
assert (fiber1.state == Fiber.State.TERM && fiber2.state == Fiber.State.TERM);
}
If your fiber-function never yield()s, then it is not cooperative, which means that once execution enters that function, other fibers will not finish their work.
Related
Here a == 3 and the condition was true but when the setinterval runs, the value of a will be 4 then, do while will check the condition and it will be a false condition, though this will not run.
I don't see any error in this.
setinterval was blocking the next condition which will be verified but it's an infinite loop which does not end so the checking of condition will not happen but do while was executed first without checking the condition and the inside if condition was true will execute the setinterval method but the confusion created in the definition of asynchronous function definition is that (it will be multi-threaded so the execution of both will run simultaneously it will hold the execution setinterval and execute the upcoming statements) by following the definition it will check condition first but this will prove wrong the definition of do while loop because in do while the condition was checked in 2nd iteration 1st iteration will be executed without checking the condition of the loop.
var a=3;
function ali() {
console.log("testing and understanding setInterval method");
a++;
}
do {
if (a == 3)
setInterval(ali,1000);
} while (a == 3);
setInterval should run but being on asynchronous function it is running with no output. When running it it says heap stack is full in Node.js.
JavaScript is not multi-threaded. You essentially have:
condition = true;
do {
setInterval(some_function_that_changes_condition, 1000)
} while(condition);
You're right that this is an infinite loop.
This is like saying "I will continuously order pizzas until one arrives". So you start ordering pizza-after-pizza on the phone but you never answer the door when one of the pizzas actually arrives because you're busy making phone-calls to order more pizzas.
setInterval basically schedules a function to be run later, but nothing else can happen in JavaScript until you relinquish control of the JavaScript context by returning from the function that this code was written in. There is no way for JavaScript to interrupt execution of your loop to execute the callback. Maybe you're thinking that it might happen during one of the setInterval calls? But it won't.
In Node.js the timer may very well be scheduled and the thread that wants to invoke the callback function may be runnable, but the JavaScript engine itself is busy running your infinite loop and cannot be interrupted.
The timer functions never guarantee that they would run precisely after the interval. It literally says that "I will execute it soon as I get the breathing space after the specified time".
What is breathing space? Every time a function runs, the JS engine waits for the function to return. This is the breathing space. It is at that moment the JS engine checks its "Event Loop" what it has to execute next. This is the only time your timer function may be scheduled to run.
The timer never runs before the long loop is over in the following example.
function test() {
console.log('Starting')
setTimeout(()=> console.log('timer executed'), 1000)
for (let i=1; i<=9999999999; i++);
console.log('the loop is over');
}
test()
This snippet is excerpted from Monix document.
It's an example that how to enter deadlock in Scala.
import java.util.concurrent.Executors
import scala.concurrent._
implicit val ec = ExecutionContext.fromExecutor(Executors.newFixedThreadPool(1))
def addOne(x: Int) = Future(x + 1)
def multiply(x: Int, y: Int) = Future {
val a = addOne(x)
val b = addOne(y)
val result = for (r1 <- a; r2 <- b) yield r1 * r2
// This can dead-lock due to the limited size of our thread-pool!
Await.result(result, Duration.Inf)
}
I understand what the code does, but not about how it executed.
Why it is the line Await.result(result, Duration.Inf) causing the deadlock ? (Yes, I tested it)
Is not that the outermost Future at multiply function occupy all the thread pool(the single one) and thus deadlock (because the addOne future is forever blocked on waiting for thread)?
Is not that the outermost Future at multiply function occupy all the thread pool(the single one) and thus deadlock (because the addOne future is forever blocked on waiting for thread)?
Yes, sort of.
When you call val a = addOne(x), you create a new Future that starts waiting for a thread. However, as you noted, the only thread is currently in use by the outermost Future. That wouldn't be a problem without await, since Futures are able to handle this condition. However, this line:
Await.result(result, Duration.Inf)
causes the outer Future to wait for the result Future, which can't run because the outer Future is still using the only available thread. (And, of course, it also can't run because the a and b Futures can't run, again due to the outer Future.)
Here's a simpler example that also deadlocks without creating so many Futures:
def addTwo(x: Int) = Future {
Await.result(addOne(x + 1), Duration.Inf)
}
First of all I would say this code can simulate deadlock, it’s not guaranteed that it will always be in the deadlock.
What is happening in the above code. We have only a single thread in the thread pool. And as soon as we are calling the multiple function as it’s the future so it should run on a separate thread say we assign the single thread we have in the thread pool to this function.
Now the function addOne also is a future so it will again start running on the same thread, but will not wait for a=addOne to get complete and move to the next line b=addOne hence the same thread which was executing the a=addOne now executing the b=addOne and the value of all will never be calculated and that future is not complete and never going to be complete as we have only one thread, same case with the line b=addOne it control will not wait to complete that future and move to the for loop for is also async in the Scala so it will again not evaluated and move to the last line await and it will be waiting for the infinity amount of time to complete the previous futures.
Necessary and sufficient condition to get into the dead lock.
Mutual Exclusion Condition
Hold and Wait Condition
No-Preemptive Condition
Circular Wait Condition
Here we can see we have only one thread so the processes going to be execute are not mutually exclusive.
once the thread is executing specific block and hence it’s a future and not waiting to complete it, it’s going ahead and executing the next block hence it’s reaching to the await statement and the thread is holding there while all the other future which are not complete are waiting for the thread to complete the future.
Once the thread is allocated to the await it can’t be preempt that’s the reason we can’t execute the remaining future which are not complete.
And circular wait is there because awaits is waiting for the non-complete future to be complete and other futures are waiting for the await call to be complete.
Simply we can say the control will directly reach to the await statement and start waiting for the non-complete futures to got complete which is not going to be happen anyhow. Because we have only one thread in our thread pool.
Await.result(result, Duration.Inf)
When you use await, you are waiting for future to complete. And you have given infinite time. So if anyhow Future will never be able to complete, main thread go to infinite wait.
I found a piece of strange code in a open source software
for (i=0; i<store->scan_threads; i++) {
pthread_join(thread_ids[i], NULL);
pthread_detach(thread_ids[i]);
}
Is there any meaning to call pthread_detach ?
That stanza is silly and unsafe.
Design-wise, the detach is unnecessary — the join completion already means that the thread is completely finished. There's nothing to detach. (The code in question simply spawns threads with default joinability.)
Implementation-wise, the detach is unsafe. A thread ID may be recycled as soon as the thread is finished — oops, didn't mean to detach that other thread! Worse, the ID is not guaranteed to be meaningful at all after the call to join returns — SEGV?
In this code (considering that this code is from main thread.... )
pthread_join(thread_ids[i], NULL);
this will wait the main thread to return thread with thread id "thread_ids[i]", and if main thread is doing some more work then
pthread_detach(thread_ids[i]);
will release the resource used by the thread (with thread id "thread_ids[i]).
I am using two instances of System.Threading.Timer to fire off 2 tasks that are repeated periodically.
My question is: If the timer is disabled but at that point of time this timer is executing its callback on a thread, then will the Main method exit, or will it wait for the executing callbacks to complete?
In the code below, Method1RunCount is synchronized for read and write using lock statement ( this part of code is not shown below). The call back for timer1 increments Method1RunCount by 1 at end of each run.
static void Main(string[] args)
{
TimerCallback callback1 = Method1;
System.Threading.Timer timer1 = new System.Threading.Timer(callback1,null,0, 90000);
TimerCallback callback2 = Method2;
System.Threading.Timer timer2 = new System.Threading.Timer(callback2, null, 0, 60000);
while (true)
{
System.Threading.Thread.Sleep(250);
if (Method1RunCount == 4)
{
//DISABLE the TIMERS
timer1.Change(System.Threading.Timeout.Infinite, System.Threading.Timeout.Infinite);
timer2.Change(System.Threading.Timeout.Infinite, System.Threading.Timeout.Infinite);
break;
}
}
}
This kind of code tends to work by accident, the period of the timer is large enough to avoid the threading race on the Method1RunCount variable. Make the period smaller and there's a real danger that the main thread won't see the value "4" at all. Odds go down considerably when the processor is heavily loaded and the main thread doesn't get scheduled for while. The timer's callback can then execute more than once while the main thread is waiting for the processor. Completing missing the value getting incremented to 4. Note how the lock statement does not in fact prevent this, it isn't locked by the main thread since it is probably sleeping.
There's also no reasonable guess you can make at how often Method2 runs. Not just because it has a completely different timer period but fundamentally because it isn't synchronized to either the Method1 or the Main method execution at all.
You'd normally increment Method1RunCount at the end of Method1. That doesn't otherwise guarantee that Method1 won't be aborted. It runs on a threadpool thread, they have the Thread.IsBackground property always set to true. So the CLR will readily abort them when the main thread exits. This again tends to not cause a problem by accident.
If it is absolutely essential that Method1 executes exactly 4 times then the simple way to ensure that is to let Method1 do the counting. Calling Timer.Change() inside the method is fine. Use a class like AutoResetEvent to let the main thread know about it. Which now no longer needs the Sleep anymore. You still need a lock to ensure that Method1 cannot be re-entered while it is executing. A good way to know that you are getting thread synchronization wrong is when you see yourself using Thread.Sleep().
From the docs on System.Threading.Timer (http://msdn.microsoft.com/en-us/library/system.threading.timer.aspx):
When a timer is no longer needed, use the Dispose method to free the
resources held by the timer. Note that callbacks can occur after the
Dispose() method overload has been called, because the timer queues
callbacks for execution by thread pool threads. You can use the
Dispose(WaitHandle) method overload to wait until all callbacks have
completed.
When myThread.Start(...) is called, do we have the assurance that the thread is started? The MSDN documentation isn't really specific about that. It says that the status of is changed to Running.
I am asking because I've seen a couple of times the following code. It creates a thread, starts it and then loop until the status become Running. Is that necessary to loop?
Thread t = new Thread(new ParameterizedThreadStart(data));
t.Start(data);
while (t.ThreadState != System.Threading.ThreadState.Running &&
t.ThreadState != System.Threading.ThreadState.WaitSleepJoin)
{
Thread.Sleep(10);
}
Thanks!
If you're set on not allowing your loop to continue until the thread has "started", then it will depend on what exactly you mean by "started". Does that mean that the thread has been created by the OS and signaled to run, but not necessarily that it's done anything yet? Does that mean that it's executed one or more operations?
While it's likely fine, your loop isn't bulletproof, since it's theoretically possible that the entire thread executes between the time you call Start and when you check the ThreadState; it's also not a good idea to check the property directly twice.
If you want to stick with checking the state, something like this would/could be more reliable:
ThreadState state = t.ThreadState;
while(state != ThreadState.Runnung && state != ThreadState.WaitSleepJoin)
{
Thread.Sleep(10:
state = t.ThreadState;
}
However, this is still subject to the possibility of the thread starting, running, then stopping before you even get the chance to check. Yes, you could expand the scope of the if statement to include other states, but I would recommend using a WaitHandle to signal when the thread "starts".
ManualResetEvent signal;
void foo()
{
Thread t = new Thread(new ParameterizedThreadStart(ThreadMethod));
signal = new ManualResetEvent();
t.Start(data);
signal.WaitOne();
/* code to execute after the thread has "started" */
}
void ThreadMethod(object foo)
{
signal.Set();
/* do your work */
}
You still have the possiblity of the thread ending before you check, but you're guaranteed to have that WaitHandle set once the thread starts. The call to WaitOne will block indefinitely until Set has been called on the WaitHandle.
Guess it depends on what you are doing after the loop. If whatever comes after it critically dependant on the thread running then checking is not a bad idea. Personnally I'd use a ManualResetEvent or something similiar that was set by the Thread rather than checking the ThreadStatus
No. Thread.Start causes a "thread to be scheduled for execution". It will start, but it may take a (short) period of time before the code within your delegate actually runs. In fact, the code above doesn't do what (I suspect) the author intended, either. Setting the thread's threadstate to ThreadState.Running (which does happen in Thread.Start) just makes sure it's scheduled to run -- but the ThreadState can be "Running" before the delegate is actually executing.
As John Bergess suggested, using a ManualResetEvent to notify the main thread that the thread is running is a much better option than sleeping and checking the thread's state.