Is it possible to define and call method asynchronously in the same thread as the caller?
Suppose I have just one core and I don't want threading management overhead with like 100 threads.
Edit
The reason I ask is nodejs model of doing things - everything on one thread never blocking anything, which proved to be very efficient, which made me wonder if same stuff possible in C# (and I couldn't achieve it myself).
Edit2 Well, as noted in comments node isn't single-threaded after all (however simple load test shows, that it uses just one core...), but I think what makes it so efficient is implicit requirement to write only non-blocking code. Which is possible in C#, except not required:) Anyway, thanks everyone...
More info in
this SO post and even more in this one
It's not really clear exactly what context you're talking about, but the async/await feature of C# 5 already helps to support this sort of thing. The difference is that whereas in node.js everything is forced to be single threaded by default (as I understand it; quite possibly incorrectly given the links in the comments), server-side applications in .NET using asynchrony will use very few threads without limiting themselves to that. If everything really can be served by a single thread, it may well be - if you never have more than one thing to do in terms of physical processing, then that's fine.
But what if one request comes in while another is doing a bit of work? Maybe it's doing just a small amount of encryption, or something like that. Do you really want to make the second request wait for the first one to complete? If you do, you could model that in .NET fairly easily with a TaskScheduler associated with a single-thread thread-pool... but more commonly, you'd use the thread-pool built into .NET, which will work efficiently while still allowing concurrency.
First off, you should make sure you're using .NET 4.5 - it has far more asynchronous APIs (e.g. for database and file access) than earlier versions of .NET. You want to use APIs which conform to the Task-based Asynchronous Pattern (TAP). Then, using async/await you can write your server-side code so that it reads a bit like synchronous code, but actually executes asynchronous. So for example, you might have:
Guid userId = await FetchUserIdAsync();
IEnumerable<Message> messages = await FetchMessagesAsync(userId);
Even though you need to "wait" while each of these operations talks place, you do so without blocking a thread. The C# compiler takes care of building a state machine for you. There's no need to explicitly write callbacks which frequently turn into spaghetti code - the compiler does it all.
You need to make sure that whatever web/web-service framework you use supports asynchrony, and it should just manage the rest, using as few threads as it can get away with.
Follow the two links above to find out more about the asynchrony support in C# 5 - it's a huge topic, and I'm sure you'll have more questions afterwards, but when you've read a bit more you should be able to ask very specific questions instead of the current broad one.
Related
I'm working on a .net core library that will get used mostly in web apps. This library is being built with performance in mind as this is the main design decision. There is some code that is fairly heavy and due to this, will get cached so that subsequent calls are quick. As you can imagine, the first call is slower and I don't want that. I want to execute this code at the earliest possible time to warm up the cache without affecting the other operations. I was thinking of using Task.Start() without awaiting to to achieve this.
My question is, is it frowned upon to use threadpool threads in a library, i.e what is the etiquette on this? As this will be mostly used on web apps, I feel I don't want to interfere with the client's threadpool. That being said, the library will only use one background thread and this will be less than a second. Or should I just let the client take the performance hit for first calls?
If I understand you correctly; it's perfectly legitimate to use multi-threading in a library; as a matter of fact: it happens all the time.
Basically, a lot of async Task methods do this in one way or another. (Sometimes there is no thread)
If it's so heavy you need multiple parallel threads for a long period in time, than it's best to create an explicit initialize routine, and warn the caller in the docs.
Task.Run is typically used for such processing.
First I have developed much in C#, now I'm working on 3D web project and now the most usable language is JavaScript at the moment.
In C# until there becomes the new keywords async/await in new C# specification there was a way to make asynchronous calls by using:
delegates
Begin/End functions, like: BeginInvoke, EndInvoke
IAsync interface
As for JS... Right now I have a need to use some parallel computations and really need a stuff, which is similar to asynchronous work with some locking models like Semaphore, Mutex or other..
As for async/await... I have tried the promises concept, which is implemented in jQuery with its deferred promise:
http://api.jquery.com/deferred.promise/
http://api.jquery.com/category/deferred-object/
It remains me async/await concept in C#:
http://msdn.microsoft.com/en-us/library/hh191443.aspx
But I've also have found such concept as WebWorkers:
https://developer.mozilla.org/en-US/docs/Web/Guide/Performance/Using_web_workers
When I first read it, I think it could be also a solution except promises pattern, but if to look from the point of implementing I understand WebWorkers are launching from other threads than a main page execution thread and the functions aren't really asynchronous, they're just callbacks with one option, that they have been added to the Worker() instance, which can be used in main page thread, am I right?
So... I wonder, how can I also implement something similar to the Semaphore in JavaScript?
Thanks!
UPDATE #1 ( more a reply to Doge ):
Let me describe you a simple example, there is an application, which I'm developing.
I already using the jQuery deferred object for one thing to await all the texture images I've received, which I was awaiting for.
The link is the next: http://bit.ly/O2dZmQ
It's an webgl application with the three.js library, which is building houses on real data (ps: don't look into code, I know it's not good :) I only recently understand the prototype way of programming in js :) first I was too used to C# and its paradigms ).
So... I have such a task. I must wait when all the textures will be loaded from AJAX and only then I'm setting them as textures for meshes.
Right now... When I've created this question, I thought about redeveloping the source code and thought about WebWorkers use.
What have I think first, which I want to do and what I've done when developed WPF/Silverlight application in C#.
I've done another instance of Worker, which will check asynchronously the task I've described above.
And I have done a very tiny and simple example which I want to use, but have a fail.
As I saw WebWorkers don't accept objects if I want to send it to worker. Alright...
Passing objects to a web worker
There is a JSON.stringify() method... But I've see another thing... JSON.stringify() can't parse an object to string where the are circular references.
Chrome sendrequest error: TypeError: Converting circular structure to JSON
Truly... It's rather disappointing... Because if there is C# or even C++ it's NOT a problem to exchange between instances some objects... Some things could be done with some reinterpret casts or other stuff... And it's not a problem to exchange objects even between different threads even in asynchronous work...
So... For the my aim... What is the best solution? Keep the deffered/promises pattern and not to use WebWorkers?
The tiny source, not full application, but just for a small example, what I want to do:
http://pastebin.com/5ernFNme ( need HTML for JS, which is below )
http://pastebin.com/ELcw7SuE ( JS main logic )
http://pastebin.com/PuHrhW8n ( WebWorker, which I suppose to use as for separate checker )
Textures for a tiny sample:
http://s14.postimg.org/wqm0xb2ep/box.jpg
http://s27.postimg.org/nc77umytv/box2.jpg
Minified three.js could be found here:
https://github.com/mrdoob/three.js/blob/master/build/three.min.js
It's important to understand that JavaScript has no threads. It has an event loop that executes events, one-by-one, as they come in.
The consequence of this is that if you have a process that takes a while you're blocking all execution. If JavaScript is also needed to do UI stuff like responding to user events or animations, it's a bit of snag. You could try to split up your process into multiple events to keep the event loop running smoothly but that's not always easy to do.
This is where Workers come it. Workers run in their own thread. To avoid issues related to threads the workers don't share memory.
You can communicate with a worker by sending and receiving messages. The messages in turn come in the event loop, so you don't need semaphores or anything that synchronizes threads. If your worker controller is in JavaScript there are never any atomicity issues.
If your workers are simple input->output workers then you can totally slap a Promise layer on top of that. Just keep in mind that Promises themselves don't add threads or asynchronousness.
You can only send Workers messages, that is: strings. You can't send them objects, and certainly not objects that might have references to other objects because again: memory issues.
If I look at your use case I guess the only reason why you might want the Workers is to take advantage of multiple cores that most CPUs have nowadays.
I think what you're doing is loading images as textures into your canvas, and that's what takes up a lot of time? There is no good way to use Workers here since the Worker would need a reference to the canvas, and that's not happening.
Now if instead you needed to do processing on the textures to transform them in some way you could use Workers. Send the image data as a binary string, possibly base64_encoded, do the conversion and send it back. If your image is large the serialization will also take up a fair chunk of CPU time so your mileage may vary.
From what I can tell your resources load pretty quick and there doesn't seem to be a CPU bottleneck. So I don't know if you really need the Workers.
Is it still necessary to use the lock keyword on resources like SQL Compact database in methods called with async (AsyncCtpLibrary.dll)? As i understand from the talk given by Anders, the async processing all happens within the same thread, so they shouldn't be a need for it, or am I wrong? I cannot find any info on this anywhere on the internet at the moment.
Thanks
AFAIK async is based on the TPL and Tasks - and so no they won't be running on the same thread every time (or continue on the same thread) and yes you have to design with concurency in mind still. Async only helps you to put the pieces together in a much nicer way.
To be clear: everything inside your methods (if started only once) will run in a thread at a time but if you share resources you will have to think on locking or other synchronization methods just as you used to do all the time.
If you can go for immutable data - this way you can strip all this to a mere minimum, but you allway have to remember that your processes will run on many threads (dispatch for UI comes to mind).
When calling runtime.GOMAXPROCS(1) in go the runtime will only use one thread for all your goroutines. When doing io your goroutines will yield and let the other goroutines run on the same thread.
This seem very similar to me to how the .net Async CTP feature is doing cooperative concurrency if you are not using background thread.
My question is which advantage or drawback could you think of one methode over the other.
Making value judgements is always a tricky thing so I'll highlight 3 differences. You decide whether they fall into the "pro" or "con" bucket.
While both Go and async allow you to write async code in a straightforward way, in .NET you have to be aware which part of your code is async and which one isn't (i.e. you have to explicitly use async/await keywords). In Go you don't need to know that - the runtime makes it "just work", there is no special syntax to mark async code.
Go design doesn't require any special code in standard library. .NET required adding new code to the standard library for every async operation, essentially doubling API surface for those cases e.g. there's new async http download API and the old, non-async http download API has to remain for backwards compatibility.
Go design and implementation is orders of magnitude simpler. A small piece of runtime code (scheduler) takes care of suspending goroutines that block on system calls and yielding to sleeping goroutines. There is no need for any special async support in standard library.
.NET implementation first required adding the aforementioned new APIs. Furthermore .NET implementation is based on compiler rewriting code with async/await into an equivalent state machines. It's very clever but also rather complicated. The practical result was that the first async CTP had known bugs while Go's implementation was working pretty much from the beginning.
Ultimately, it doesn't really matter. async/await is the best way to write async code in .NET. Goroutines are the best way to get that in Go. Both are great, especially compared to alternatives in most other languages.
When do you use threads in a application? For example, in simple CRUD operations, use of smtp, calling webservices that may take a few time if the server is facing bandwith issues, etc.
To be honest, i don't know how to determine if i need to use a thread (i know that it must be when we're excepting that a operation will take a few time to be done).
This may be a "noob" question but it'll be great if you share with me your experience in threads.
Thanks
I added C# and .NET tags to your question because you mention C# in your title. If that is not accurate, feel free to remove the tags.
There are different styles of multithreading. For example, there are asynchronous operations with callback functions. .NET 4 introduces the parallel Linq library. The style of multithreading you would use, or whether to use any at all, depends on what you are trying to accomplish.
Parallel execution, such as what parallel Linq would generally be trying to do, takes advantage of multiple processor cores executing instructions that do not need to wait for data from each other. There are many sources for such algorithms outside Linq, such as this. However, it is possible that parallel execution may be unable to you or that it does not suit your application.
More traditional multithreading takes advantage of threading within the .NET library (in this case) as provided by System.Thread. Remember that there is some overhead in starting processes on threads, so only use threads when the advantages of doing so outweigh this overhead. Generally speaking, you would only want to use this type of single-processor multithreading when the task running under the thread will have long gaps in which the processor could be doing something else. For example, I/O from hard disk (and, consequently, from a database system that uses one) is many orders of magnitude slower than memory access. Network access can also be slow, as another example. Multithreading could allow another process to be running while waiting for these slow (compared to the processor) operations to complete.
Another example when I have used traditional multithreading is to cache some values the first time a particular ASP.NET page is accessed within a session. I kick off a thread so that the user does not have to wait for the caching to complete before interacting with the page. I also regulate the behavior when the caching does not complete before the user requests another page so that, if the caching does not complete, it is not a problem. It simply makes some further requests faster that were previously too slow.
Consider also the cost that multithreading has to the maintainability of your application. Threaded applications can be harder to debug, for example.
I hope this answers your question at least somewhat.
Joseph Albahari summarized it very well here:
Maintaining a responsive user interface
Making efficient use of an otherwise blocked CPU
Parallel programming
Speculative execution
Allowing requests to be processed simultaneously
One reason to use threads is to split large, CPU-bound tasks across a number of CPUs/cores, to finish faster. Another is to let an extended task execute asynchronously, so the foreground can remain responsive while it runs.
Your examples seem to be concentrating on the second of these. While it can be a good reason, if you can use asynchronous I/O instead, that's usually preferable (e.g., almost anything using sockets can/will be better off using the socket(s) asynchronously). Asynchronous I/O is easier to cancel, and it'll usually have lower CPU overhead as well.
You can use threads when you need different execution paths. This leads(when done correctly) to more responsive and/or faster applications but also leads to more complex code and debugging.
In a simple CRUD scenario maybe is not that useful, but maybe your UI is consuming a slow web service. If you your code is tied to your UI thread you will have unresponsive UI between the service calls.
In that case, using System.Threading.Threads maybe be overkill because you don't need so much control. Using a BackgrounWorker maybe a better choice.
Threading is something difficult to master, but the benefits when used correctly are huge, performance is the most common.
Somehow you have answered your question by yourself. Using threads whenever you execute time consuming operations is right choice. Also you should it in situations when you want to make things faster. For example you want to process some amount of files - each file can be processed by different thread.
By using threads you can better utilize power of multi-core/processor machines.
Monitoring some data in background of your application.
There are dozens of such scenarios.
Realising my comment might suffice as an answer ...
I like to view multi-threading scenarios from a resource perspective. In other words, UI (graphics), networking, disk IO, CPU (cores), RAM etc. I find that helps when deciding where to use multi-threading in the general sense at least.
The reasoning behind this is simply that I can take advantage of one resource on a specific thread (eg. Disk IO) while at the same time using another thread to accomplish something else using a different resource.