I was going through some tutorial on SystemC and there was a mention that we cant put wait in SC_METHOD, it didn't explain why.
That is because SC_METHOD does not have its own thread of execution. Every time an event on an SC_METHOD sensitivity list is triggered, the SC_METHOD's code is (ideally) entirely executed. In other words, calling wait() in an SC_METHOD would freeze the simulation itself.
In contrast, an SC_THREAD has its own thread of execution and its activity is generally modeled inside a loop containing or not wait() statements, which pauses the execution of the thread. Whenever an event (of the sensitivity list) is triggered, the execution is resumed at the command that follows the previously issued wait().
Its a feature of the language. SC_METHOD is meant to executed to completion without being deferred or losing context, unlike SC_THREAD.
Related
When looking through boost asio co_spawn documentation (https://www.boost.org/doc/libs/1_78_0/doc/html/boost_asio/reference/co_spawn/overload6.html), I see this statement, "Spawn a new coroutined-based thread of execution", however my understanding is that co_spawn does not create an actual thread, but uses threads that are part of the boost::asio::io_context pool. It's a "coroutine-based thread of execution" in a sense, that this coroutine would be a root of all coroutines that are spawned from inside this one
Is my understanding correct here or an actual thread is created whenever co_spawn is used like this:
::boost::asio::co_spawn(io_ctx, [&] -> ::boost::asio::awaitable<void> {
// do something
}, ::boost::asio::detached);
thanks!
It does not. See The Proactor Design Pattern: Concurrency Without Threads and https://www.boost.org/doc/libs/1_78_0/doc/html/boost_asio/overview/core/threads.html
What does detached mean/do? The documentation says:
The detached_t class is used to indicate that an asynchronous operation is detached. That is, there is no completion handler waiting for the operation's result.
It comes down to writing a no-op handler but (a) less work (b) more room for the library to optimize.
Another angle to look at this from is this: if the execution context for the executor (io_ctx) is never run/polled, nothing will ever happen. As always in boost, you decide where you run the service (whether you use threads e.g.)
Lets say, i have a complex calculation running in NSOperation block. I have paused it. Closed the app. Then restarted the app. Can i recover the last state and continue from there?
Is there existing solution for such a problem or it can be only custom built for certain purposes?
The question is a bit vague, so it's hard to say without knowing all of the code in play. With that said, I may approach the problem by:
Option 1. In your subclass of NSOperation, add your own atomic KVO property "isPaused". Within the operation itself, observe that property and handle accordingly if it ever changes.
Option 2. Are you ever suspending the Operation Queue itself? If so, consider observing that property from within your operations, and each one independently can take action if that value changes.
Option 3. Cancel all operations in the queue, and if the view appears again, just restart with new operations.
Overall, though, there is no magic bullet for pausing operations already in progress. You'll have to bake your own solution. The damage shouldn't be too bad though.
Suspending and Resuming Queues If you want to issue a temporary halt to the execution of operations, you can suspend the corresponding operation queue using the setSuspended: method.
Suspending a queue does not cause already executing operations to pause in the middle of their tasks. It simply prevents new operations from being scheduled for execution. You might suspend a queue in response to a user request to pause any ongoing work, because the expectation is that the user might eventually want to resume that work.
For more detail Refer this link apple docs: http://developer.apple.com/library/mac/#documentation/General/Conceptual/ConcurrencyProgrammingGuide/OperationObjects/OperationObjects.html
If I had a block like so:
(void) ^contrivedExample = ^{//some expensive operation//};
And use it like so:
int test = 1;
contrivedExample()
test++;
Since incrementing test takes no time, will this only occur after my block has fully executed?
Yes, they will hold execution. The increment will occur only after your expensive block finishes executing.
If you need to brush up on your blocks, here's a good read on the matter:
https://developer.apple.com/library/ios/documentation/cocoa/Conceptual/Blocks/Articles/00_Introduction.html
Yes. Incrementing test will occur after the block has completely finished executing. Blocks aren't asynchronous in and of themselves, although they are often used by APIs that are asynchronous.
Yes. You can even have it run on a different thread by calling either dispatch_sync or dispatch_async.
dispatch_sync means the block runs on a different thread, while the current thread waits for the block to complete.
dispatch_async sends the block to another thread and the current thread continues.
If I have a background thread doing some network stuff, and some of the background methods make 'performSelectorOnMainThread' calls, will/can these calls interrupt execution of the current code block (which is being executed on the main thread)?
No, they will and can not. The performSelector group of methods schedule actions on the run loop. Only after your current code block returns to the run loop, these actions will be performed. (Assuming with "the current code block" you mean your code running on the main thread)
If waitUntilDone is set to YES, then absolutely it will definitely interrupt execution of the code calling performSelectorOnMainThread. If it's set to NO then it will queue the selector to be performed on the main thread.
If the caller of performSelectorOnMainThread is not the main thread, then whether or not the selector gets run before your "current code block" finishes will depend entirely upon the state the CPU is in. There might be more than one CPU so you might have 2 of your threads scheduled at the same time, or just the OS might have decided to schedule the main thread instead of your current thread after some time.
So basically, yes, these calls can interrupt execution of the current code block, just in the same way as you should be familiar with from multi-threaded programming.
[By "current code block" I am assuming you mean the caller of performSelectorOnMainThread]
Update:
Ah, right, you mean "Can it interrupt the code which is currently being executed on the main thread?". The answer to that, is definitely not. It is scheduled on the main thread's run loop to run next time round the loop.
I am in the middle of creating a cloud integration framework for iOS. We allow you to save, query, count and remove with synchronous and asynchronous with selector/callback and block implementations. What is the correct practice? Running the completion blocks on the main thread or a background thread?
For simple cases, I just parameterize it and do all the work i can on secondary threads:
By default, callbacks will be made on any thread (where it is most efficient and direct - typically once the operation has completed). This is the default because messaging via main can be quite costly.
The client may optionally specify that the message must be made on the main thread. This way, it requires one line or argument. If safety is more important than efficiency, then you may want to invert the default value.
You could also attempt to batch and coalesce some messages, or simply use a timer on the main run loop to vend.
Consider both joined and detached models for some of your work.
If you can reduce the task to a result (remove the capability for incremental updates, if not needed), then you can simply run the task, do the work, and provide the result (or error) when complete.
Apple's NSURLConnection class calls back to its delegate methods on the thread from which it was initiated, while doing its work on a background thread. That seems like a sensible procedure. It's likely that a user of your framework will not enjoy having to worry about thread safety when writing a simple callback block, as they would if you created a new thread to run it on.
The two sides of the coin: If the callback touches the GUI, it has to be run on the main thread. On the other hand, if it doesn't, and is going to do a lot of work, running it on the main thread will block the GUI, causing frustration for the end user.
It's probably best to put the callback on a known, documented thread, and let the app programmer make the determination of the effect on the GUI.