Aren't the guidelines of async/await usage in C# contradicting the concepts of good architecture and...











up vote
63
down vote

favorite
13












This question concerns the C# language, but I expect it to cover other languages such as Java or TypeScript.



Microsoft recommends best practices on using asynchronous calls in .NET. Among these recommendations, let's pick two:




  • change the signature of the async methods so that they return Task or Task<> (in TypeScript, that'd be a Promise<>)

  • change the names of the async methods to end with xxxAsync()


Now, when replacing a low-level, synchronous component by an async one, this impacts the full stack of the application. Since async/await has a positive impact only if used "all the way up", it means the signature and method names of every layer in the application must be changed.



A good architecture often involves placing abstractions between each layers, such that replacing low-level components by others is unseen by the upper-level components. In C#, abstractions take the form of interfaces. If we introduce a new, low-level, async component, each interface in the call stack needs to be either modified or replaced by a new interface. The way a problem is solved (async or sync) in an implementing class is not hidden (abstracted) to the callers anymore. The callers have to know if it's sync or async.



Aren't async/await best practices contradicting with "good architecture" principles?



Does it mean that each interface (say IEnumerable, IDataAccessLayer) needs their async counterpart (IAsyncEnumerable, IAsyncDataAccessLayer) such that they can be replaced in the stack when switching to async dependencies?



If we push the problem a little further, wouldn't it be simpler to assume every method to be async (to return a Task<> or Promise<>), and for the methods to synchronize the async calls when they're not actually async? Is this something to be expected from the future programming languages?










share|improve this question









New contributor




corentinaltepe is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 3




    While this sounds like a great discussion question, I think this is too opinion-based to be answered here.
    – Euphoric
    yesterday






  • 15




    @Euphoric: I think the problem scetched here goes deeper than the C# guidelines, that's just a symptom of the fact that changing parts of an application to asynchronous behaviour can have non-local effects on the overall system. So my gut tells me there must be a non-opinionated answer for this, based on technical facts. Hence, I encourage everyone here not to close this question too early, instead let us wait what answers will come (and if they are too opinionated, we can still vote for closing).
    – Doc Brown
    yesterday








  • 18




    @DocBrown I think the deeper question here is "Can part of system be changed from synchronous to asynchronous without parts that depend on it also having to change?" I think the answer to that is clear "no". In that case, I don't see how "concepts of good architecture and layering" apply here.
    – Euphoric
    yesterday






  • 3




    @Euphoric: sounds like a good basis for a non-opinionated answer ;-)
    – Doc Brown
    yesterday






  • 2




    Yes, this is a significant downside to using async. In my opinion, this downside is widely underestimated in the community.
    – usr
    yesterday















up vote
63
down vote

favorite
13












This question concerns the C# language, but I expect it to cover other languages such as Java or TypeScript.



Microsoft recommends best practices on using asynchronous calls in .NET. Among these recommendations, let's pick two:




  • change the signature of the async methods so that they return Task or Task<> (in TypeScript, that'd be a Promise<>)

  • change the names of the async methods to end with xxxAsync()


Now, when replacing a low-level, synchronous component by an async one, this impacts the full stack of the application. Since async/await has a positive impact only if used "all the way up", it means the signature and method names of every layer in the application must be changed.



A good architecture often involves placing abstractions between each layers, such that replacing low-level components by others is unseen by the upper-level components. In C#, abstractions take the form of interfaces. If we introduce a new, low-level, async component, each interface in the call stack needs to be either modified or replaced by a new interface. The way a problem is solved (async or sync) in an implementing class is not hidden (abstracted) to the callers anymore. The callers have to know if it's sync or async.



Aren't async/await best practices contradicting with "good architecture" principles?



Does it mean that each interface (say IEnumerable, IDataAccessLayer) needs their async counterpart (IAsyncEnumerable, IAsyncDataAccessLayer) such that they can be replaced in the stack when switching to async dependencies?



If we push the problem a little further, wouldn't it be simpler to assume every method to be async (to return a Task<> or Promise<>), and for the methods to synchronize the async calls when they're not actually async? Is this something to be expected from the future programming languages?










share|improve this question









New contributor




corentinaltepe is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 3




    While this sounds like a great discussion question, I think this is too opinion-based to be answered here.
    – Euphoric
    yesterday






  • 15




    @Euphoric: I think the problem scetched here goes deeper than the C# guidelines, that's just a symptom of the fact that changing parts of an application to asynchronous behaviour can have non-local effects on the overall system. So my gut tells me there must be a non-opinionated answer for this, based on technical facts. Hence, I encourage everyone here not to close this question too early, instead let us wait what answers will come (and if they are too opinionated, we can still vote for closing).
    – Doc Brown
    yesterday








  • 18




    @DocBrown I think the deeper question here is "Can part of system be changed from synchronous to asynchronous without parts that depend on it also having to change?" I think the answer to that is clear "no". In that case, I don't see how "concepts of good architecture and layering" apply here.
    – Euphoric
    yesterday






  • 3




    @Euphoric: sounds like a good basis for a non-opinionated answer ;-)
    – Doc Brown
    yesterday






  • 2




    Yes, this is a significant downside to using async. In my opinion, this downside is widely underestimated in the community.
    – usr
    yesterday













up vote
63
down vote

favorite
13









up vote
63
down vote

favorite
13






13





This question concerns the C# language, but I expect it to cover other languages such as Java or TypeScript.



Microsoft recommends best practices on using asynchronous calls in .NET. Among these recommendations, let's pick two:




  • change the signature of the async methods so that they return Task or Task<> (in TypeScript, that'd be a Promise<>)

  • change the names of the async methods to end with xxxAsync()


Now, when replacing a low-level, synchronous component by an async one, this impacts the full stack of the application. Since async/await has a positive impact only if used "all the way up", it means the signature and method names of every layer in the application must be changed.



A good architecture often involves placing abstractions between each layers, such that replacing low-level components by others is unseen by the upper-level components. In C#, abstractions take the form of interfaces. If we introduce a new, low-level, async component, each interface in the call stack needs to be either modified or replaced by a new interface. The way a problem is solved (async or sync) in an implementing class is not hidden (abstracted) to the callers anymore. The callers have to know if it's sync or async.



Aren't async/await best practices contradicting with "good architecture" principles?



Does it mean that each interface (say IEnumerable, IDataAccessLayer) needs their async counterpart (IAsyncEnumerable, IAsyncDataAccessLayer) such that they can be replaced in the stack when switching to async dependencies?



If we push the problem a little further, wouldn't it be simpler to assume every method to be async (to return a Task<> or Promise<>), and for the methods to synchronize the async calls when they're not actually async? Is this something to be expected from the future programming languages?










share|improve this question









New contributor




corentinaltepe is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











This question concerns the C# language, but I expect it to cover other languages such as Java or TypeScript.



Microsoft recommends best practices on using asynchronous calls in .NET. Among these recommendations, let's pick two:




  • change the signature of the async methods so that they return Task or Task<> (in TypeScript, that'd be a Promise<>)

  • change the names of the async methods to end with xxxAsync()


Now, when replacing a low-level, synchronous component by an async one, this impacts the full stack of the application. Since async/await has a positive impact only if used "all the way up", it means the signature and method names of every layer in the application must be changed.



A good architecture often involves placing abstractions between each layers, such that replacing low-level components by others is unseen by the upper-level components. In C#, abstractions take the form of interfaces. If we introduce a new, low-level, async component, each interface in the call stack needs to be either modified or replaced by a new interface. The way a problem is solved (async or sync) in an implementing class is not hidden (abstracted) to the callers anymore. The callers have to know if it's sync or async.



Aren't async/await best practices contradicting with "good architecture" principles?



Does it mean that each interface (say IEnumerable, IDataAccessLayer) needs their async counterpart (IAsyncEnumerable, IAsyncDataAccessLayer) such that they can be replaced in the stack when switching to async dependencies?



If we push the problem a little further, wouldn't it be simpler to assume every method to be async (to return a Task<> or Promise<>), and for the methods to synchronize the async calls when they're not actually async? Is this something to be expected from the future programming languages?







c# architecture async






share|improve this question









New contributor




corentinaltepe is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




corentinaltepe is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited 18 hours ago









Peter Mortensen

1,11621114




1,11621114






New contributor




corentinaltepe is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked yesterday









corentinaltepe

42425




42425




New contributor




corentinaltepe is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





corentinaltepe is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






corentinaltepe is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








  • 3




    While this sounds like a great discussion question, I think this is too opinion-based to be answered here.
    – Euphoric
    yesterday






  • 15




    @Euphoric: I think the problem scetched here goes deeper than the C# guidelines, that's just a symptom of the fact that changing parts of an application to asynchronous behaviour can have non-local effects on the overall system. So my gut tells me there must be a non-opinionated answer for this, based on technical facts. Hence, I encourage everyone here not to close this question too early, instead let us wait what answers will come (and if they are too opinionated, we can still vote for closing).
    – Doc Brown
    yesterday








  • 18




    @DocBrown I think the deeper question here is "Can part of system be changed from synchronous to asynchronous without parts that depend on it also having to change?" I think the answer to that is clear "no". In that case, I don't see how "concepts of good architecture and layering" apply here.
    – Euphoric
    yesterday






  • 3




    @Euphoric: sounds like a good basis for a non-opinionated answer ;-)
    – Doc Brown
    yesterday






  • 2




    Yes, this is a significant downside to using async. In my opinion, this downside is widely underestimated in the community.
    – usr
    yesterday














  • 3




    While this sounds like a great discussion question, I think this is too opinion-based to be answered here.
    – Euphoric
    yesterday






  • 15




    @Euphoric: I think the problem scetched here goes deeper than the C# guidelines, that's just a symptom of the fact that changing parts of an application to asynchronous behaviour can have non-local effects on the overall system. So my gut tells me there must be a non-opinionated answer for this, based on technical facts. Hence, I encourage everyone here not to close this question too early, instead let us wait what answers will come (and if they are too opinionated, we can still vote for closing).
    – Doc Brown
    yesterday








  • 18




    @DocBrown I think the deeper question here is "Can part of system be changed from synchronous to asynchronous without parts that depend on it also having to change?" I think the answer to that is clear "no". In that case, I don't see how "concepts of good architecture and layering" apply here.
    – Euphoric
    yesterday






  • 3




    @Euphoric: sounds like a good basis for a non-opinionated answer ;-)
    – Doc Brown
    yesterday






  • 2




    Yes, this is a significant downside to using async. In my opinion, this downside is widely underestimated in the community.
    – usr
    yesterday








3




3




While this sounds like a great discussion question, I think this is too opinion-based to be answered here.
– Euphoric
yesterday




While this sounds like a great discussion question, I think this is too opinion-based to be answered here.
– Euphoric
yesterday




15




15




@Euphoric: I think the problem scetched here goes deeper than the C# guidelines, that's just a symptom of the fact that changing parts of an application to asynchronous behaviour can have non-local effects on the overall system. So my gut tells me there must be a non-opinionated answer for this, based on technical facts. Hence, I encourage everyone here not to close this question too early, instead let us wait what answers will come (and if they are too opinionated, we can still vote for closing).
– Doc Brown
yesterday






@Euphoric: I think the problem scetched here goes deeper than the C# guidelines, that's just a symptom of the fact that changing parts of an application to asynchronous behaviour can have non-local effects on the overall system. So my gut tells me there must be a non-opinionated answer for this, based on technical facts. Hence, I encourage everyone here not to close this question too early, instead let us wait what answers will come (and if they are too opinionated, we can still vote for closing).
– Doc Brown
yesterday






18




18




@DocBrown I think the deeper question here is "Can part of system be changed from synchronous to asynchronous without parts that depend on it also having to change?" I think the answer to that is clear "no". In that case, I don't see how "concepts of good architecture and layering" apply here.
– Euphoric
yesterday




@DocBrown I think the deeper question here is "Can part of system be changed from synchronous to asynchronous without parts that depend on it also having to change?" I think the answer to that is clear "no". In that case, I don't see how "concepts of good architecture and layering" apply here.
– Euphoric
yesterday




3




3




@Euphoric: sounds like a good basis for a non-opinionated answer ;-)
– Doc Brown
yesterday




@Euphoric: sounds like a good basis for a non-opinionated answer ;-)
– Doc Brown
yesterday




2




2




Yes, this is a significant downside to using async. In my opinion, this downside is widely underestimated in the community.
– usr
yesterday




Yes, this is a significant downside to using async. In my opinion, this downside is widely underestimated in the community.
– usr
yesterday










5 Answers
5






active

oldest

votes

















up vote
82
down vote



accepted










What Color Is Your Function?



You may be interested in Bob Nystrom's What Color Is Your Function1.



In this article, he describes a fictional language where:




  • Each function has a color: blue or red.

  • A red function may call either blue or red functions, no issue.

  • A blue function may only call blue functions.


While fictitious, this happens quite regularly in programming languages:




  • In C++, a "const" method may only call other "const" methods on this.

  • In Haskell, a non-IO function may only call non-IO functions.

  • In C#, a sync function may only call sync functions2.


As you have realized, because of these rules, red functions tend to spread around the code base. You insert one, and little by little it colonizes the whole code base.



1Bob Nystrom, apart from blogging, is also part of the Dart team and has written this little Crafting Interpreters serie; highly recommended for any programming language/compiler afficionado.



2Not quite true, as you may call an async function and block until it returns, but...



Language Limitation



This is, essentially, a language/run-time limitation.



Language with M:N threading, for example, such as Erlang and Go, do not have async functions: each function is potentially async and its "fiber" will simply be suspended, swapped out, and swapped back in when it's ready again.



C# went with a 1:1 threading model, and therefore decided to surface synchronicity in the language to avoid accidentally blocking threads.



In the presence of language limitations, coding guidelines have to adapt.






share|improve this answer

















  • 3




    IO functions do have a tendency to spread, but with diligence, you can mostly isolate them to functions near (in the stack when calling) entry points of your code. You can do this by having those functions call the IO functions and then have other functions process the output from them and return any results needed for further IO. I find that this style makes my code bases much easier to manage and work with. I wonder if there's a corollary with synchronicity.
    – jpmc26
    yesterday








  • 8




    What do you mean by "M:N" and "1:1" threading?
    – Captain Man
    yesterday










  • @jpmc26: Mostly, indeed. Isolating I/O at the boundary also makes it easier to unit-test. The one special-case, though, is logging.
    – Matthieu M.
    yesterday






  • 9




    @CaptainMan: 1:1 threading means mapping one application thread to one OS thread, this is the case in languages such as C, C++, Java or C#. By contrast, M:N threading means mapping M applications threads to N OS threads; in the case of Go, an application thread is called a "goroutine", in the case of Erlang, it's called an "actor", and you may also have heard of them as "green threads" or "fibers". They provide concurrency without requiring parallelism. Unfortunately the Wikipedia article on the topic is rather sparse.
    – Matthieu M.
    yesterday




















up vote
61
down vote













You are right there is a contradiction here, but it is not the "best practices" being bad. It is because asynchronous function does essentially different thing than a synchronous one. Instead of waiting for the result from its dependencies (usually some IO) it creates a task to be handled by the main event loop. This is not a difference which can be well hidden under abstraction.






share|improve this answer



















  • 16




    The answer is as simple as this IMO. The difference between a synchronous and asynchronous process isn't an implementation detail - it's a semantically different contract.
    – Ant P
    yesterday






  • 3




    @AntP: I disagree that it's that simple; it surfaces in the C# language, but not in the Go language for example. So this is not an inherent property of asynchronous processes, it's a matter of how asynchronous processes are modeled in the given language.
    – Matthieu M.
    21 hours ago


















up vote
4
down vote













An asynchronous method behaves differently than one which is synchronous, as I'm sure you're aware. At runtime, to convert an async call to a synchronous one is trivial, but the opposite cannot be said. So therefore the logic then becomes, why don't we make async methods of every method which may require it and let the caller "convert" as necessary to a synchronous method?



In a sense it is like having a method which throws exceptions and another which is "safe" and won't throw even in case of error. At what point is the coder being excessive to provide these methods which otherwise can be converted one to another?



In this there are two schools of thought: one is to create multiple methods, each one calling another possibly private method allowing for the possibility of providing optional parameters or minor alterations to behavior such as being asynchronous. The other is to minimize interface methods to bare essentials leaving it up to the caller to perform the necessary modifications himself/herself.



If you're of the first school, there's a certain logic to dedicating a class towards synchronous and asynchronous calls in order to avoid doubling every call. Microsoft tends to favor this school of thought, and by convention, to remain consistent with the style favored by Microsoft, you too would have to have an Async version, in much the same way that interfaces almost always start with an "I". Let me stress that it isn't wrong, per se, because it is better to keep a consistent style in a project rather than do it "the right way" and radically change style for the development that you add to a project.



That said, I tend to favor the second school, which is to minimize interface methods. If I think a method may be called in an asynchronous way, the method for me is asynchronous. The caller can decide whether or not to wait for that task to finish before proceeding. If this interface is an interface to a library, there is more reasonable to do it this way to minimize the number of methods you'd need to deprecate or adjust. If the interface is for internal use in my project, I will add a method for every needed call throughout my project for the parameters provided and no "extra" methods, and even then, only if the behavior of the method isn't already covered by an existing method.



However, like many things in this field, it's largely subjective. Both approaches have their pros and cons. Microsoft also started the convention of adding letters indicative of type at the beginning of the variable name, and "m_" to indicate it is a member, leading to variable names like m_pUser. My point being that not even Microsoft is infallible, and can make mistakes too.



That said, if your project is following this Async convention, I would advise you to respect it and continue the style. And only once you're given a project of your own, you can write it in the best way you see fit.






share|improve this answer

















  • 3




    "At runtime, to convert an async call to a synchronous one is trivial" I'm not sure it is exactly so. In .NET, using .Wait() method and like can cause negative consequences, and in js, as far as I know, it is not possible at all.
    – max630
    yesterday






  • 2




    @max630 I didn't say there aren't concurrent issues to consider, but if it was initially a synchronous task, chances are it's not creating deadlocks. That said, trivial does not mean "double click here to convert to synchronous". In js, you return a Promise instance, and call resolve on it.
    – Neil
    yesterday








  • 2




    yeah its totally a pain in the arse to convert async back to sync
    – Ewan
    yesterday






  • 4




    @Neil In javascript, even if you call Promise.resolve(x) and then add callbacks to it, those callbacks won't be executed immediately.
    – NickL
    yesterday










  • It really is trivial to convert async to sync. But you have to be careful about which thread you're blocking, and you can only do it at most once in any particular call graph -- if you have multiple layers mixing up synchronous and asynchronous calls, then you are in for a world of pain.
    – Miral
    yesterday


















up vote
0
down vote













Let's imagine there is a way to enable you to call functions in an async way without changing their signature.



That would be really cool and no-one would recommend you change their names.



But, actual asynchronous functions, not just ones that await another async function, but the lowest level have some structure to them specific to their async nature. eg



public class HTTPClient
{
public HTTPResponse GET()
{
//send data
while(!timedOut)
{
//check for response
if(response) {
this.GotResponse(response);
}
this.YouCanWait();
}
}

//tell calling code that they should watch for this event
public EventHander GotResponse
//indicate to calling code that they can go and do something else for a bit
public EventHander YouCanWait;
}


It's those two bit of information that the calling code needs in order to run the code in an async way that things like Task and async encapsulate.



There is more than one way to do asynchronous functions, async Task is just one pattern built into the compiler via return types so that you don't have to manually link up the events






share|improve this answer




























    up vote
    0
    down vote













    I will address the main point in a less C#ness fashion and more generic :




    Aren't async/await best practices contradicting with "good architecture" principles?




    I would say that it just depends of the choice you make in the design of your API and what you let to the user.



    If you want one function of your API to be only async there is little interest into following the naming convention. Just always return Task<>/Promise<>/Future<>/... as return type, it is self documenting. If wants a synchronise answer, he will still be able to do that by waiting, but if he always do that, it make a bit of boilerplate.



    However if you make only your API sync, that mean that if a user want it to be async, he will have to manage the async part of it himself.



    This can make quite a lot of extra work, however it can also give more control to the user about how many concurrent call he allows, place timeout, retrys and so on.



    In a large system with a huge API, implementing most of them to be sync by default might be easier and more efficient than managing independently each part of your API, specially if they share ressources (filesystem, CPU, database, ...).



    In fact for the most complex parts, you could perfectly have two implementations of the same part of your API, one synchronous doing the handy stuff, one asynchronous relying on the synchronous one do handle stuff and only managing concurrency, loads, timeouts, and retries.



    Maybe someone else can share his experience with that because I lack experience with such systems.






    share|improve this answer

















    • 2




      @Miral You've used "call an async method from a sync method" in both possibilities.
      – Adrian Wragg
      19 hours ago










    • @AdrianWragg So I did; my brain must have had a race condition. I'll fix it.
      – Miral
      4 hours ago










    • It's the other way around; it's trivial to call an async method from a sync method, but it's impossible to call a sync method from an async method. (And where things completely fall apart is when someone tries to do the latter anyway, which can lead to deadlocks.) So if you had to pick one, async by default is the better choice. Unfortunately it's also the harder choice, because an async implementation can only call async methods.
      – Miral
      4 hours ago










    • (And by this I of course mean a blocking sync method. You can call something that makes a pure CPU-bound calculation synchronously from an async method -- although you should try to avoid doing it unless you know you're in a worker context rather than a UI context -- but blocking calls that wait idle on a lock or for I/O or for another operation are a bad idea.)
      – Miral
      4 hours ago











    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "131"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });






    corentinaltepe is a new contributor. Be nice, and check out our Code of Conduct.










    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsoftwareengineering.stackexchange.com%2fquestions%2f382486%2farent-the-guidelines-of-async-await-usage-in-c-contradicting-the-concepts-of-g%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    5 Answers
    5






    active

    oldest

    votes








    5 Answers
    5






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    82
    down vote



    accepted










    What Color Is Your Function?



    You may be interested in Bob Nystrom's What Color Is Your Function1.



    In this article, he describes a fictional language where:




    • Each function has a color: blue or red.

    • A red function may call either blue or red functions, no issue.

    • A blue function may only call blue functions.


    While fictitious, this happens quite regularly in programming languages:




    • In C++, a "const" method may only call other "const" methods on this.

    • In Haskell, a non-IO function may only call non-IO functions.

    • In C#, a sync function may only call sync functions2.


    As you have realized, because of these rules, red functions tend to spread around the code base. You insert one, and little by little it colonizes the whole code base.



    1Bob Nystrom, apart from blogging, is also part of the Dart team and has written this little Crafting Interpreters serie; highly recommended for any programming language/compiler afficionado.



    2Not quite true, as you may call an async function and block until it returns, but...



    Language Limitation



    This is, essentially, a language/run-time limitation.



    Language with M:N threading, for example, such as Erlang and Go, do not have async functions: each function is potentially async and its "fiber" will simply be suspended, swapped out, and swapped back in when it's ready again.



    C# went with a 1:1 threading model, and therefore decided to surface synchronicity in the language to avoid accidentally blocking threads.



    In the presence of language limitations, coding guidelines have to adapt.






    share|improve this answer

















    • 3




      IO functions do have a tendency to spread, but with diligence, you can mostly isolate them to functions near (in the stack when calling) entry points of your code. You can do this by having those functions call the IO functions and then have other functions process the output from them and return any results needed for further IO. I find that this style makes my code bases much easier to manage and work with. I wonder if there's a corollary with synchronicity.
      – jpmc26
      yesterday








    • 8




      What do you mean by "M:N" and "1:1" threading?
      – Captain Man
      yesterday










    • @jpmc26: Mostly, indeed. Isolating I/O at the boundary also makes it easier to unit-test. The one special-case, though, is logging.
      – Matthieu M.
      yesterday






    • 9




      @CaptainMan: 1:1 threading means mapping one application thread to one OS thread, this is the case in languages such as C, C++, Java or C#. By contrast, M:N threading means mapping M applications threads to N OS threads; in the case of Go, an application thread is called a "goroutine", in the case of Erlang, it's called an "actor", and you may also have heard of them as "green threads" or "fibers". They provide concurrency without requiring parallelism. Unfortunately the Wikipedia article on the topic is rather sparse.
      – Matthieu M.
      yesterday

















    up vote
    82
    down vote



    accepted










    What Color Is Your Function?



    You may be interested in Bob Nystrom's What Color Is Your Function1.



    In this article, he describes a fictional language where:




    • Each function has a color: blue or red.

    • A red function may call either blue or red functions, no issue.

    • A blue function may only call blue functions.


    While fictitious, this happens quite regularly in programming languages:




    • In C++, a "const" method may only call other "const" methods on this.

    • In Haskell, a non-IO function may only call non-IO functions.

    • In C#, a sync function may only call sync functions2.


    As you have realized, because of these rules, red functions tend to spread around the code base. You insert one, and little by little it colonizes the whole code base.



    1Bob Nystrom, apart from blogging, is also part of the Dart team and has written this little Crafting Interpreters serie; highly recommended for any programming language/compiler afficionado.



    2Not quite true, as you may call an async function and block until it returns, but...



    Language Limitation



    This is, essentially, a language/run-time limitation.



    Language with M:N threading, for example, such as Erlang and Go, do not have async functions: each function is potentially async and its "fiber" will simply be suspended, swapped out, and swapped back in when it's ready again.



    C# went with a 1:1 threading model, and therefore decided to surface synchronicity in the language to avoid accidentally blocking threads.



    In the presence of language limitations, coding guidelines have to adapt.






    share|improve this answer

















    • 3




      IO functions do have a tendency to spread, but with diligence, you can mostly isolate them to functions near (in the stack when calling) entry points of your code. You can do this by having those functions call the IO functions and then have other functions process the output from them and return any results needed for further IO. I find that this style makes my code bases much easier to manage and work with. I wonder if there's a corollary with synchronicity.
      – jpmc26
      yesterday








    • 8




      What do you mean by "M:N" and "1:1" threading?
      – Captain Man
      yesterday










    • @jpmc26: Mostly, indeed. Isolating I/O at the boundary also makes it easier to unit-test. The one special-case, though, is logging.
      – Matthieu M.
      yesterday






    • 9




      @CaptainMan: 1:1 threading means mapping one application thread to one OS thread, this is the case in languages such as C, C++, Java or C#. By contrast, M:N threading means mapping M applications threads to N OS threads; in the case of Go, an application thread is called a "goroutine", in the case of Erlang, it's called an "actor", and you may also have heard of them as "green threads" or "fibers". They provide concurrency without requiring parallelism. Unfortunately the Wikipedia article on the topic is rather sparse.
      – Matthieu M.
      yesterday















    up vote
    82
    down vote



    accepted







    up vote
    82
    down vote



    accepted






    What Color Is Your Function?



    You may be interested in Bob Nystrom's What Color Is Your Function1.



    In this article, he describes a fictional language where:




    • Each function has a color: blue or red.

    • A red function may call either blue or red functions, no issue.

    • A blue function may only call blue functions.


    While fictitious, this happens quite regularly in programming languages:




    • In C++, a "const" method may only call other "const" methods on this.

    • In Haskell, a non-IO function may only call non-IO functions.

    • In C#, a sync function may only call sync functions2.


    As you have realized, because of these rules, red functions tend to spread around the code base. You insert one, and little by little it colonizes the whole code base.



    1Bob Nystrom, apart from blogging, is also part of the Dart team and has written this little Crafting Interpreters serie; highly recommended for any programming language/compiler afficionado.



    2Not quite true, as you may call an async function and block until it returns, but...



    Language Limitation



    This is, essentially, a language/run-time limitation.



    Language with M:N threading, for example, such as Erlang and Go, do not have async functions: each function is potentially async and its "fiber" will simply be suspended, swapped out, and swapped back in when it's ready again.



    C# went with a 1:1 threading model, and therefore decided to surface synchronicity in the language to avoid accidentally blocking threads.



    In the presence of language limitations, coding guidelines have to adapt.






    share|improve this answer












    What Color Is Your Function?



    You may be interested in Bob Nystrom's What Color Is Your Function1.



    In this article, he describes a fictional language where:




    • Each function has a color: blue or red.

    • A red function may call either blue or red functions, no issue.

    • A blue function may only call blue functions.


    While fictitious, this happens quite regularly in programming languages:




    • In C++, a "const" method may only call other "const" methods on this.

    • In Haskell, a non-IO function may only call non-IO functions.

    • In C#, a sync function may only call sync functions2.


    As you have realized, because of these rules, red functions tend to spread around the code base. You insert one, and little by little it colonizes the whole code base.



    1Bob Nystrom, apart from blogging, is also part of the Dart team and has written this little Crafting Interpreters serie; highly recommended for any programming language/compiler afficionado.



    2Not quite true, as you may call an async function and block until it returns, but...



    Language Limitation



    This is, essentially, a language/run-time limitation.



    Language with M:N threading, for example, such as Erlang and Go, do not have async functions: each function is potentially async and its "fiber" will simply be suspended, swapped out, and swapped back in when it's ready again.



    C# went with a 1:1 threading model, and therefore decided to surface synchronicity in the language to avoid accidentally blocking threads.



    In the presence of language limitations, coding guidelines have to adapt.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered yesterday









    Matthieu M.

    11.5k33755




    11.5k33755








    • 3




      IO functions do have a tendency to spread, but with diligence, you can mostly isolate them to functions near (in the stack when calling) entry points of your code. You can do this by having those functions call the IO functions and then have other functions process the output from them and return any results needed for further IO. I find that this style makes my code bases much easier to manage and work with. I wonder if there's a corollary with synchronicity.
      – jpmc26
      yesterday








    • 8




      What do you mean by "M:N" and "1:1" threading?
      – Captain Man
      yesterday










    • @jpmc26: Mostly, indeed. Isolating I/O at the boundary also makes it easier to unit-test. The one special-case, though, is logging.
      – Matthieu M.
      yesterday






    • 9




      @CaptainMan: 1:1 threading means mapping one application thread to one OS thread, this is the case in languages such as C, C++, Java or C#. By contrast, M:N threading means mapping M applications threads to N OS threads; in the case of Go, an application thread is called a "goroutine", in the case of Erlang, it's called an "actor", and you may also have heard of them as "green threads" or "fibers". They provide concurrency without requiring parallelism. Unfortunately the Wikipedia article on the topic is rather sparse.
      – Matthieu M.
      yesterday
















    • 3




      IO functions do have a tendency to spread, but with diligence, you can mostly isolate them to functions near (in the stack when calling) entry points of your code. You can do this by having those functions call the IO functions and then have other functions process the output from them and return any results needed for further IO. I find that this style makes my code bases much easier to manage and work with. I wonder if there's a corollary with synchronicity.
      – jpmc26
      yesterday








    • 8




      What do you mean by "M:N" and "1:1" threading?
      – Captain Man
      yesterday










    • @jpmc26: Mostly, indeed. Isolating I/O at the boundary also makes it easier to unit-test. The one special-case, though, is logging.
      – Matthieu M.
      yesterday






    • 9




      @CaptainMan: 1:1 threading means mapping one application thread to one OS thread, this is the case in languages such as C, C++, Java or C#. By contrast, M:N threading means mapping M applications threads to N OS threads; in the case of Go, an application thread is called a "goroutine", in the case of Erlang, it's called an "actor", and you may also have heard of them as "green threads" or "fibers". They provide concurrency without requiring parallelism. Unfortunately the Wikipedia article on the topic is rather sparse.
      – Matthieu M.
      yesterday










    3




    3




    IO functions do have a tendency to spread, but with diligence, you can mostly isolate them to functions near (in the stack when calling) entry points of your code. You can do this by having those functions call the IO functions and then have other functions process the output from them and return any results needed for further IO. I find that this style makes my code bases much easier to manage and work with. I wonder if there's a corollary with synchronicity.
    – jpmc26
    yesterday






    IO functions do have a tendency to spread, but with diligence, you can mostly isolate them to functions near (in the stack when calling) entry points of your code. You can do this by having those functions call the IO functions and then have other functions process the output from them and return any results needed for further IO. I find that this style makes my code bases much easier to manage and work with. I wonder if there's a corollary with synchronicity.
    – jpmc26
    yesterday






    8




    8




    What do you mean by "M:N" and "1:1" threading?
    – Captain Man
    yesterday




    What do you mean by "M:N" and "1:1" threading?
    – Captain Man
    yesterday












    @jpmc26: Mostly, indeed. Isolating I/O at the boundary also makes it easier to unit-test. The one special-case, though, is logging.
    – Matthieu M.
    yesterday




    @jpmc26: Mostly, indeed. Isolating I/O at the boundary also makes it easier to unit-test. The one special-case, though, is logging.
    – Matthieu M.
    yesterday




    9




    9




    @CaptainMan: 1:1 threading means mapping one application thread to one OS thread, this is the case in languages such as C, C++, Java or C#. By contrast, M:N threading means mapping M applications threads to N OS threads; in the case of Go, an application thread is called a "goroutine", in the case of Erlang, it's called an "actor", and you may also have heard of them as "green threads" or "fibers". They provide concurrency without requiring parallelism. Unfortunately the Wikipedia article on the topic is rather sparse.
    – Matthieu M.
    yesterday






    @CaptainMan: 1:1 threading means mapping one application thread to one OS thread, this is the case in languages such as C, C++, Java or C#. By contrast, M:N threading means mapping M applications threads to N OS threads; in the case of Go, an application thread is called a "goroutine", in the case of Erlang, it's called an "actor", and you may also have heard of them as "green threads" or "fibers". They provide concurrency without requiring parallelism. Unfortunately the Wikipedia article on the topic is rather sparse.
    – Matthieu M.
    yesterday














    up vote
    61
    down vote













    You are right there is a contradiction here, but it is not the "best practices" being bad. It is because asynchronous function does essentially different thing than a synchronous one. Instead of waiting for the result from its dependencies (usually some IO) it creates a task to be handled by the main event loop. This is not a difference which can be well hidden under abstraction.






    share|improve this answer



















    • 16




      The answer is as simple as this IMO. The difference between a synchronous and asynchronous process isn't an implementation detail - it's a semantically different contract.
      – Ant P
      yesterday






    • 3




      @AntP: I disagree that it's that simple; it surfaces in the C# language, but not in the Go language for example. So this is not an inherent property of asynchronous processes, it's a matter of how asynchronous processes are modeled in the given language.
      – Matthieu M.
      21 hours ago















    up vote
    61
    down vote













    You are right there is a contradiction here, but it is not the "best practices" being bad. It is because asynchronous function does essentially different thing than a synchronous one. Instead of waiting for the result from its dependencies (usually some IO) it creates a task to be handled by the main event loop. This is not a difference which can be well hidden under abstraction.






    share|improve this answer



















    • 16




      The answer is as simple as this IMO. The difference between a synchronous and asynchronous process isn't an implementation detail - it's a semantically different contract.
      – Ant P
      yesterday






    • 3




      @AntP: I disagree that it's that simple; it surfaces in the C# language, but not in the Go language for example. So this is not an inherent property of asynchronous processes, it's a matter of how asynchronous processes are modeled in the given language.
      – Matthieu M.
      21 hours ago













    up vote
    61
    down vote










    up vote
    61
    down vote









    You are right there is a contradiction here, but it is not the "best practices" being bad. It is because asynchronous function does essentially different thing than a synchronous one. Instead of waiting for the result from its dependencies (usually some IO) it creates a task to be handled by the main event loop. This is not a difference which can be well hidden under abstraction.






    share|improve this answer














    You are right there is a contradiction here, but it is not the "best practices" being bad. It is because asynchronous function does essentially different thing than a synchronous one. Instead of waiting for the result from its dependencies (usually some IO) it creates a task to be handled by the main event loop. This is not a difference which can be well hidden under abstraction.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited yesterday

























    answered yesterday









    max630

    1,550513




    1,550513








    • 16




      The answer is as simple as this IMO. The difference between a synchronous and asynchronous process isn't an implementation detail - it's a semantically different contract.
      – Ant P
      yesterday






    • 3




      @AntP: I disagree that it's that simple; it surfaces in the C# language, but not in the Go language for example. So this is not an inherent property of asynchronous processes, it's a matter of how asynchronous processes are modeled in the given language.
      – Matthieu M.
      21 hours ago














    • 16




      The answer is as simple as this IMO. The difference between a synchronous and asynchronous process isn't an implementation detail - it's a semantically different contract.
      – Ant P
      yesterday






    • 3




      @AntP: I disagree that it's that simple; it surfaces in the C# language, but not in the Go language for example. So this is not an inherent property of asynchronous processes, it's a matter of how asynchronous processes are modeled in the given language.
      – Matthieu M.
      21 hours ago








    16




    16




    The answer is as simple as this IMO. The difference between a synchronous and asynchronous process isn't an implementation detail - it's a semantically different contract.
    – Ant P
    yesterday




    The answer is as simple as this IMO. The difference between a synchronous and asynchronous process isn't an implementation detail - it's a semantically different contract.
    – Ant P
    yesterday




    3




    3




    @AntP: I disagree that it's that simple; it surfaces in the C# language, but not in the Go language for example. So this is not an inherent property of asynchronous processes, it's a matter of how asynchronous processes are modeled in the given language.
    – Matthieu M.
    21 hours ago




    @AntP: I disagree that it's that simple; it surfaces in the C# language, but not in the Go language for example. So this is not an inherent property of asynchronous processes, it's a matter of how asynchronous processes are modeled in the given language.
    – Matthieu M.
    21 hours ago










    up vote
    4
    down vote













    An asynchronous method behaves differently than one which is synchronous, as I'm sure you're aware. At runtime, to convert an async call to a synchronous one is trivial, but the opposite cannot be said. So therefore the logic then becomes, why don't we make async methods of every method which may require it and let the caller "convert" as necessary to a synchronous method?



    In a sense it is like having a method which throws exceptions and another which is "safe" and won't throw even in case of error. At what point is the coder being excessive to provide these methods which otherwise can be converted one to another?



    In this there are two schools of thought: one is to create multiple methods, each one calling another possibly private method allowing for the possibility of providing optional parameters or minor alterations to behavior such as being asynchronous. The other is to minimize interface methods to bare essentials leaving it up to the caller to perform the necessary modifications himself/herself.



    If you're of the first school, there's a certain logic to dedicating a class towards synchronous and asynchronous calls in order to avoid doubling every call. Microsoft tends to favor this school of thought, and by convention, to remain consistent with the style favored by Microsoft, you too would have to have an Async version, in much the same way that interfaces almost always start with an "I". Let me stress that it isn't wrong, per se, because it is better to keep a consistent style in a project rather than do it "the right way" and radically change style for the development that you add to a project.



    That said, I tend to favor the second school, which is to minimize interface methods. If I think a method may be called in an asynchronous way, the method for me is asynchronous. The caller can decide whether or not to wait for that task to finish before proceeding. If this interface is an interface to a library, there is more reasonable to do it this way to minimize the number of methods you'd need to deprecate or adjust. If the interface is for internal use in my project, I will add a method for every needed call throughout my project for the parameters provided and no "extra" methods, and even then, only if the behavior of the method isn't already covered by an existing method.



    However, like many things in this field, it's largely subjective. Both approaches have their pros and cons. Microsoft also started the convention of adding letters indicative of type at the beginning of the variable name, and "m_" to indicate it is a member, leading to variable names like m_pUser. My point being that not even Microsoft is infallible, and can make mistakes too.



    That said, if your project is following this Async convention, I would advise you to respect it and continue the style. And only once you're given a project of your own, you can write it in the best way you see fit.






    share|improve this answer

















    • 3




      "At runtime, to convert an async call to a synchronous one is trivial" I'm not sure it is exactly so. In .NET, using .Wait() method and like can cause negative consequences, and in js, as far as I know, it is not possible at all.
      – max630
      yesterday






    • 2




      @max630 I didn't say there aren't concurrent issues to consider, but if it was initially a synchronous task, chances are it's not creating deadlocks. That said, trivial does not mean "double click here to convert to synchronous". In js, you return a Promise instance, and call resolve on it.
      – Neil
      yesterday








    • 2




      yeah its totally a pain in the arse to convert async back to sync
      – Ewan
      yesterday






    • 4




      @Neil In javascript, even if you call Promise.resolve(x) and then add callbacks to it, those callbacks won't be executed immediately.
      – NickL
      yesterday










    • It really is trivial to convert async to sync. But you have to be careful about which thread you're blocking, and you can only do it at most once in any particular call graph -- if you have multiple layers mixing up synchronous and asynchronous calls, then you are in for a world of pain.
      – Miral
      yesterday















    up vote
    4
    down vote













    An asynchronous method behaves differently than one which is synchronous, as I'm sure you're aware. At runtime, to convert an async call to a synchronous one is trivial, but the opposite cannot be said. So therefore the logic then becomes, why don't we make async methods of every method which may require it and let the caller "convert" as necessary to a synchronous method?



    In a sense it is like having a method which throws exceptions and another which is "safe" and won't throw even in case of error. At what point is the coder being excessive to provide these methods which otherwise can be converted one to another?



    In this there are two schools of thought: one is to create multiple methods, each one calling another possibly private method allowing for the possibility of providing optional parameters or minor alterations to behavior such as being asynchronous. The other is to minimize interface methods to bare essentials leaving it up to the caller to perform the necessary modifications himself/herself.



    If you're of the first school, there's a certain logic to dedicating a class towards synchronous and asynchronous calls in order to avoid doubling every call. Microsoft tends to favor this school of thought, and by convention, to remain consistent with the style favored by Microsoft, you too would have to have an Async version, in much the same way that interfaces almost always start with an "I". Let me stress that it isn't wrong, per se, because it is better to keep a consistent style in a project rather than do it "the right way" and radically change style for the development that you add to a project.



    That said, I tend to favor the second school, which is to minimize interface methods. If I think a method may be called in an asynchronous way, the method for me is asynchronous. The caller can decide whether or not to wait for that task to finish before proceeding. If this interface is an interface to a library, there is more reasonable to do it this way to minimize the number of methods you'd need to deprecate or adjust. If the interface is for internal use in my project, I will add a method for every needed call throughout my project for the parameters provided and no "extra" methods, and even then, only if the behavior of the method isn't already covered by an existing method.



    However, like many things in this field, it's largely subjective. Both approaches have their pros and cons. Microsoft also started the convention of adding letters indicative of type at the beginning of the variable name, and "m_" to indicate it is a member, leading to variable names like m_pUser. My point being that not even Microsoft is infallible, and can make mistakes too.



    That said, if your project is following this Async convention, I would advise you to respect it and continue the style. And only once you're given a project of your own, you can write it in the best way you see fit.






    share|improve this answer

















    • 3




      "At runtime, to convert an async call to a synchronous one is trivial" I'm not sure it is exactly so. In .NET, using .Wait() method and like can cause negative consequences, and in js, as far as I know, it is not possible at all.
      – max630
      yesterday






    • 2




      @max630 I didn't say there aren't concurrent issues to consider, but if it was initially a synchronous task, chances are it's not creating deadlocks. That said, trivial does not mean "double click here to convert to synchronous". In js, you return a Promise instance, and call resolve on it.
      – Neil
      yesterday








    • 2




      yeah its totally a pain in the arse to convert async back to sync
      – Ewan
      yesterday






    • 4




      @Neil In javascript, even if you call Promise.resolve(x) and then add callbacks to it, those callbacks won't be executed immediately.
      – NickL
      yesterday










    • It really is trivial to convert async to sync. But you have to be careful about which thread you're blocking, and you can only do it at most once in any particular call graph -- if you have multiple layers mixing up synchronous and asynchronous calls, then you are in for a world of pain.
      – Miral
      yesterday













    up vote
    4
    down vote










    up vote
    4
    down vote









    An asynchronous method behaves differently than one which is synchronous, as I'm sure you're aware. At runtime, to convert an async call to a synchronous one is trivial, but the opposite cannot be said. So therefore the logic then becomes, why don't we make async methods of every method which may require it and let the caller "convert" as necessary to a synchronous method?



    In a sense it is like having a method which throws exceptions and another which is "safe" and won't throw even in case of error. At what point is the coder being excessive to provide these methods which otherwise can be converted one to another?



    In this there are two schools of thought: one is to create multiple methods, each one calling another possibly private method allowing for the possibility of providing optional parameters or minor alterations to behavior such as being asynchronous. The other is to minimize interface methods to bare essentials leaving it up to the caller to perform the necessary modifications himself/herself.



    If you're of the first school, there's a certain logic to dedicating a class towards synchronous and asynchronous calls in order to avoid doubling every call. Microsoft tends to favor this school of thought, and by convention, to remain consistent with the style favored by Microsoft, you too would have to have an Async version, in much the same way that interfaces almost always start with an "I". Let me stress that it isn't wrong, per se, because it is better to keep a consistent style in a project rather than do it "the right way" and radically change style for the development that you add to a project.



    That said, I tend to favor the second school, which is to minimize interface methods. If I think a method may be called in an asynchronous way, the method for me is asynchronous. The caller can decide whether or not to wait for that task to finish before proceeding. If this interface is an interface to a library, there is more reasonable to do it this way to minimize the number of methods you'd need to deprecate or adjust. If the interface is for internal use in my project, I will add a method for every needed call throughout my project for the parameters provided and no "extra" methods, and even then, only if the behavior of the method isn't already covered by an existing method.



    However, like many things in this field, it's largely subjective. Both approaches have their pros and cons. Microsoft also started the convention of adding letters indicative of type at the beginning of the variable name, and "m_" to indicate it is a member, leading to variable names like m_pUser. My point being that not even Microsoft is infallible, and can make mistakes too.



    That said, if your project is following this Async convention, I would advise you to respect it and continue the style. And only once you're given a project of your own, you can write it in the best way you see fit.






    share|improve this answer












    An asynchronous method behaves differently than one which is synchronous, as I'm sure you're aware. At runtime, to convert an async call to a synchronous one is trivial, but the opposite cannot be said. So therefore the logic then becomes, why don't we make async methods of every method which may require it and let the caller "convert" as necessary to a synchronous method?



    In a sense it is like having a method which throws exceptions and another which is "safe" and won't throw even in case of error. At what point is the coder being excessive to provide these methods which otherwise can be converted one to another?



    In this there are two schools of thought: one is to create multiple methods, each one calling another possibly private method allowing for the possibility of providing optional parameters or minor alterations to behavior such as being asynchronous. The other is to minimize interface methods to bare essentials leaving it up to the caller to perform the necessary modifications himself/herself.



    If you're of the first school, there's a certain logic to dedicating a class towards synchronous and asynchronous calls in order to avoid doubling every call. Microsoft tends to favor this school of thought, and by convention, to remain consistent with the style favored by Microsoft, you too would have to have an Async version, in much the same way that interfaces almost always start with an "I". Let me stress that it isn't wrong, per se, because it is better to keep a consistent style in a project rather than do it "the right way" and radically change style for the development that you add to a project.



    That said, I tend to favor the second school, which is to minimize interface methods. If I think a method may be called in an asynchronous way, the method for me is asynchronous. The caller can decide whether or not to wait for that task to finish before proceeding. If this interface is an interface to a library, there is more reasonable to do it this way to minimize the number of methods you'd need to deprecate or adjust. If the interface is for internal use in my project, I will add a method for every needed call throughout my project for the parameters provided and no "extra" methods, and even then, only if the behavior of the method isn't already covered by an existing method.



    However, like many things in this field, it's largely subjective. Both approaches have their pros and cons. Microsoft also started the convention of adding letters indicative of type at the beginning of the variable name, and "m_" to indicate it is a member, leading to variable names like m_pUser. My point being that not even Microsoft is infallible, and can make mistakes too.



    That said, if your project is following this Async convention, I would advise you to respect it and continue the style. And only once you're given a project of your own, you can write it in the best way you see fit.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered yesterday









    Neil

    18.9k3464




    18.9k3464








    • 3




      "At runtime, to convert an async call to a synchronous one is trivial" I'm not sure it is exactly so. In .NET, using .Wait() method and like can cause negative consequences, and in js, as far as I know, it is not possible at all.
      – max630
      yesterday






    • 2




      @max630 I didn't say there aren't concurrent issues to consider, but if it was initially a synchronous task, chances are it's not creating deadlocks. That said, trivial does not mean "double click here to convert to synchronous". In js, you return a Promise instance, and call resolve on it.
      – Neil
      yesterday








    • 2




      yeah its totally a pain in the arse to convert async back to sync
      – Ewan
      yesterday






    • 4




      @Neil In javascript, even if you call Promise.resolve(x) and then add callbacks to it, those callbacks won't be executed immediately.
      – NickL
      yesterday










    • It really is trivial to convert async to sync. But you have to be careful about which thread you're blocking, and you can only do it at most once in any particular call graph -- if you have multiple layers mixing up synchronous and asynchronous calls, then you are in for a world of pain.
      – Miral
      yesterday














    • 3




      "At runtime, to convert an async call to a synchronous one is trivial" I'm not sure it is exactly so. In .NET, using .Wait() method and like can cause negative consequences, and in js, as far as I know, it is not possible at all.
      – max630
      yesterday






    • 2




      @max630 I didn't say there aren't concurrent issues to consider, but if it was initially a synchronous task, chances are it's not creating deadlocks. That said, trivial does not mean "double click here to convert to synchronous". In js, you return a Promise instance, and call resolve on it.
      – Neil
      yesterday








    • 2




      yeah its totally a pain in the arse to convert async back to sync
      – Ewan
      yesterday






    • 4




      @Neil In javascript, even if you call Promise.resolve(x) and then add callbacks to it, those callbacks won't be executed immediately.
      – NickL
      yesterday










    • It really is trivial to convert async to sync. But you have to be careful about which thread you're blocking, and you can only do it at most once in any particular call graph -- if you have multiple layers mixing up synchronous and asynchronous calls, then you are in for a world of pain.
      – Miral
      yesterday








    3




    3




    "At runtime, to convert an async call to a synchronous one is trivial" I'm not sure it is exactly so. In .NET, using .Wait() method and like can cause negative consequences, and in js, as far as I know, it is not possible at all.
    – max630
    yesterday




    "At runtime, to convert an async call to a synchronous one is trivial" I'm not sure it is exactly so. In .NET, using .Wait() method and like can cause negative consequences, and in js, as far as I know, it is not possible at all.
    – max630
    yesterday




    2




    2




    @max630 I didn't say there aren't concurrent issues to consider, but if it was initially a synchronous task, chances are it's not creating deadlocks. That said, trivial does not mean "double click here to convert to synchronous". In js, you return a Promise instance, and call resolve on it.
    – Neil
    yesterday






    @max630 I didn't say there aren't concurrent issues to consider, but if it was initially a synchronous task, chances are it's not creating deadlocks. That said, trivial does not mean "double click here to convert to synchronous". In js, you return a Promise instance, and call resolve on it.
    – Neil
    yesterday






    2




    2




    yeah its totally a pain in the arse to convert async back to sync
    – Ewan
    yesterday




    yeah its totally a pain in the arse to convert async back to sync
    – Ewan
    yesterday




    4




    4




    @Neil In javascript, even if you call Promise.resolve(x) and then add callbacks to it, those callbacks won't be executed immediately.
    – NickL
    yesterday




    @Neil In javascript, even if you call Promise.resolve(x) and then add callbacks to it, those callbacks won't be executed immediately.
    – NickL
    yesterday












    It really is trivial to convert async to sync. But you have to be careful about which thread you're blocking, and you can only do it at most once in any particular call graph -- if you have multiple layers mixing up synchronous and asynchronous calls, then you are in for a world of pain.
    – Miral
    yesterday




    It really is trivial to convert async to sync. But you have to be careful about which thread you're blocking, and you can only do it at most once in any particular call graph -- if you have multiple layers mixing up synchronous and asynchronous calls, then you are in for a world of pain.
    – Miral
    yesterday










    up vote
    0
    down vote













    Let's imagine there is a way to enable you to call functions in an async way without changing their signature.



    That would be really cool and no-one would recommend you change their names.



    But, actual asynchronous functions, not just ones that await another async function, but the lowest level have some structure to them specific to their async nature. eg



    public class HTTPClient
    {
    public HTTPResponse GET()
    {
    //send data
    while(!timedOut)
    {
    //check for response
    if(response) {
    this.GotResponse(response);
    }
    this.YouCanWait();
    }
    }

    //tell calling code that they should watch for this event
    public EventHander GotResponse
    //indicate to calling code that they can go and do something else for a bit
    public EventHander YouCanWait;
    }


    It's those two bit of information that the calling code needs in order to run the code in an async way that things like Task and async encapsulate.



    There is more than one way to do asynchronous functions, async Task is just one pattern built into the compiler via return types so that you don't have to manually link up the events






    share|improve this answer

























      up vote
      0
      down vote













      Let's imagine there is a way to enable you to call functions in an async way without changing their signature.



      That would be really cool and no-one would recommend you change their names.



      But, actual asynchronous functions, not just ones that await another async function, but the lowest level have some structure to them specific to their async nature. eg



      public class HTTPClient
      {
      public HTTPResponse GET()
      {
      //send data
      while(!timedOut)
      {
      //check for response
      if(response) {
      this.GotResponse(response);
      }
      this.YouCanWait();
      }
      }

      //tell calling code that they should watch for this event
      public EventHander GotResponse
      //indicate to calling code that they can go and do something else for a bit
      public EventHander YouCanWait;
      }


      It's those two bit of information that the calling code needs in order to run the code in an async way that things like Task and async encapsulate.



      There is more than one way to do asynchronous functions, async Task is just one pattern built into the compiler via return types so that you don't have to manually link up the events






      share|improve this answer























        up vote
        0
        down vote










        up vote
        0
        down vote









        Let's imagine there is a way to enable you to call functions in an async way without changing their signature.



        That would be really cool and no-one would recommend you change their names.



        But, actual asynchronous functions, not just ones that await another async function, but the lowest level have some structure to them specific to their async nature. eg



        public class HTTPClient
        {
        public HTTPResponse GET()
        {
        //send data
        while(!timedOut)
        {
        //check for response
        if(response) {
        this.GotResponse(response);
        }
        this.YouCanWait();
        }
        }

        //tell calling code that they should watch for this event
        public EventHander GotResponse
        //indicate to calling code that they can go and do something else for a bit
        public EventHander YouCanWait;
        }


        It's those two bit of information that the calling code needs in order to run the code in an async way that things like Task and async encapsulate.



        There is more than one way to do asynchronous functions, async Task is just one pattern built into the compiler via return types so that you don't have to manually link up the events






        share|improve this answer












        Let's imagine there is a way to enable you to call functions in an async way without changing their signature.



        That would be really cool and no-one would recommend you change their names.



        But, actual asynchronous functions, not just ones that await another async function, but the lowest level have some structure to them specific to their async nature. eg



        public class HTTPClient
        {
        public HTTPResponse GET()
        {
        //send data
        while(!timedOut)
        {
        //check for response
        if(response) {
        this.GotResponse(response);
        }
        this.YouCanWait();
        }
        }

        //tell calling code that they should watch for this event
        public EventHander GotResponse
        //indicate to calling code that they can go and do something else for a bit
        public EventHander YouCanWait;
        }


        It's those two bit of information that the calling code needs in order to run the code in an async way that things like Task and async encapsulate.



        There is more than one way to do asynchronous functions, async Task is just one pattern built into the compiler via return types so that you don't have to manually link up the events







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered yesterday









        Ewan

        37.3k32982




        37.3k32982






















            up vote
            0
            down vote













            I will address the main point in a less C#ness fashion and more generic :




            Aren't async/await best practices contradicting with "good architecture" principles?




            I would say that it just depends of the choice you make in the design of your API and what you let to the user.



            If you want one function of your API to be only async there is little interest into following the naming convention. Just always return Task<>/Promise<>/Future<>/... as return type, it is self documenting. If wants a synchronise answer, he will still be able to do that by waiting, but if he always do that, it make a bit of boilerplate.



            However if you make only your API sync, that mean that if a user want it to be async, he will have to manage the async part of it himself.



            This can make quite a lot of extra work, however it can also give more control to the user about how many concurrent call he allows, place timeout, retrys and so on.



            In a large system with a huge API, implementing most of them to be sync by default might be easier and more efficient than managing independently each part of your API, specially if they share ressources (filesystem, CPU, database, ...).



            In fact for the most complex parts, you could perfectly have two implementations of the same part of your API, one synchronous doing the handy stuff, one asynchronous relying on the synchronous one do handle stuff and only managing concurrency, loads, timeouts, and retries.



            Maybe someone else can share his experience with that because I lack experience with such systems.






            share|improve this answer

















            • 2




              @Miral You've used "call an async method from a sync method" in both possibilities.
              – Adrian Wragg
              19 hours ago










            • @AdrianWragg So I did; my brain must have had a race condition. I'll fix it.
              – Miral
              4 hours ago










            • It's the other way around; it's trivial to call an async method from a sync method, but it's impossible to call a sync method from an async method. (And where things completely fall apart is when someone tries to do the latter anyway, which can lead to deadlocks.) So if you had to pick one, async by default is the better choice. Unfortunately it's also the harder choice, because an async implementation can only call async methods.
              – Miral
              4 hours ago










            • (And by this I of course mean a blocking sync method. You can call something that makes a pure CPU-bound calculation synchronously from an async method -- although you should try to avoid doing it unless you know you're in a worker context rather than a UI context -- but blocking calls that wait idle on a lock or for I/O or for another operation are a bad idea.)
              – Miral
              4 hours ago















            up vote
            0
            down vote













            I will address the main point in a less C#ness fashion and more generic :




            Aren't async/await best practices contradicting with "good architecture" principles?




            I would say that it just depends of the choice you make in the design of your API and what you let to the user.



            If you want one function of your API to be only async there is little interest into following the naming convention. Just always return Task<>/Promise<>/Future<>/... as return type, it is self documenting. If wants a synchronise answer, he will still be able to do that by waiting, but if he always do that, it make a bit of boilerplate.



            However if you make only your API sync, that mean that if a user want it to be async, he will have to manage the async part of it himself.



            This can make quite a lot of extra work, however it can also give more control to the user about how many concurrent call he allows, place timeout, retrys and so on.



            In a large system with a huge API, implementing most of them to be sync by default might be easier and more efficient than managing independently each part of your API, specially if they share ressources (filesystem, CPU, database, ...).



            In fact for the most complex parts, you could perfectly have two implementations of the same part of your API, one synchronous doing the handy stuff, one asynchronous relying on the synchronous one do handle stuff and only managing concurrency, loads, timeouts, and retries.



            Maybe someone else can share his experience with that because I lack experience with such systems.






            share|improve this answer

















            • 2




              @Miral You've used "call an async method from a sync method" in both possibilities.
              – Adrian Wragg
              19 hours ago










            • @AdrianWragg So I did; my brain must have had a race condition. I'll fix it.
              – Miral
              4 hours ago










            • It's the other way around; it's trivial to call an async method from a sync method, but it's impossible to call a sync method from an async method. (And where things completely fall apart is when someone tries to do the latter anyway, which can lead to deadlocks.) So if you had to pick one, async by default is the better choice. Unfortunately it's also the harder choice, because an async implementation can only call async methods.
              – Miral
              4 hours ago










            • (And by this I of course mean a blocking sync method. You can call something that makes a pure CPU-bound calculation synchronously from an async method -- although you should try to avoid doing it unless you know you're in a worker context rather than a UI context -- but blocking calls that wait idle on a lock or for I/O or for another operation are a bad idea.)
              – Miral
              4 hours ago













            up vote
            0
            down vote










            up vote
            0
            down vote









            I will address the main point in a less C#ness fashion and more generic :




            Aren't async/await best practices contradicting with "good architecture" principles?




            I would say that it just depends of the choice you make in the design of your API and what you let to the user.



            If you want one function of your API to be only async there is little interest into following the naming convention. Just always return Task<>/Promise<>/Future<>/... as return type, it is self documenting. If wants a synchronise answer, he will still be able to do that by waiting, but if he always do that, it make a bit of boilerplate.



            However if you make only your API sync, that mean that if a user want it to be async, he will have to manage the async part of it himself.



            This can make quite a lot of extra work, however it can also give more control to the user about how many concurrent call he allows, place timeout, retrys and so on.



            In a large system with a huge API, implementing most of them to be sync by default might be easier and more efficient than managing independently each part of your API, specially if they share ressources (filesystem, CPU, database, ...).



            In fact for the most complex parts, you could perfectly have two implementations of the same part of your API, one synchronous doing the handy stuff, one asynchronous relying on the synchronous one do handle stuff and only managing concurrency, loads, timeouts, and retries.



            Maybe someone else can share his experience with that because I lack experience with such systems.






            share|improve this answer












            I will address the main point in a less C#ness fashion and more generic :




            Aren't async/await best practices contradicting with "good architecture" principles?




            I would say that it just depends of the choice you make in the design of your API and what you let to the user.



            If you want one function of your API to be only async there is little interest into following the naming convention. Just always return Task<>/Promise<>/Future<>/... as return type, it is self documenting. If wants a synchronise answer, he will still be able to do that by waiting, but if he always do that, it make a bit of boilerplate.



            However if you make only your API sync, that mean that if a user want it to be async, he will have to manage the async part of it himself.



            This can make quite a lot of extra work, however it can also give more control to the user about how many concurrent call he allows, place timeout, retrys and so on.



            In a large system with a huge API, implementing most of them to be sync by default might be easier and more efficient than managing independently each part of your API, specially if they share ressources (filesystem, CPU, database, ...).



            In fact for the most complex parts, you could perfectly have two implementations of the same part of your API, one synchronous doing the handy stuff, one asynchronous relying on the synchronous one do handle stuff and only managing concurrency, loads, timeouts, and retries.



            Maybe someone else can share his experience with that because I lack experience with such systems.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered yesterday









            Walfrat

            3,074725




            3,074725








            • 2




              @Miral You've used "call an async method from a sync method" in both possibilities.
              – Adrian Wragg
              19 hours ago










            • @AdrianWragg So I did; my brain must have had a race condition. I'll fix it.
              – Miral
              4 hours ago










            • It's the other way around; it's trivial to call an async method from a sync method, but it's impossible to call a sync method from an async method. (And where things completely fall apart is when someone tries to do the latter anyway, which can lead to deadlocks.) So if you had to pick one, async by default is the better choice. Unfortunately it's also the harder choice, because an async implementation can only call async methods.
              – Miral
              4 hours ago










            • (And by this I of course mean a blocking sync method. You can call something that makes a pure CPU-bound calculation synchronously from an async method -- although you should try to avoid doing it unless you know you're in a worker context rather than a UI context -- but blocking calls that wait idle on a lock or for I/O or for another operation are a bad idea.)
              – Miral
              4 hours ago














            • 2




              @Miral You've used "call an async method from a sync method" in both possibilities.
              – Adrian Wragg
              19 hours ago










            • @AdrianWragg So I did; my brain must have had a race condition. I'll fix it.
              – Miral
              4 hours ago










            • It's the other way around; it's trivial to call an async method from a sync method, but it's impossible to call a sync method from an async method. (And where things completely fall apart is when someone tries to do the latter anyway, which can lead to deadlocks.) So if you had to pick one, async by default is the better choice. Unfortunately it's also the harder choice, because an async implementation can only call async methods.
              – Miral
              4 hours ago










            • (And by this I of course mean a blocking sync method. You can call something that makes a pure CPU-bound calculation synchronously from an async method -- although you should try to avoid doing it unless you know you're in a worker context rather than a UI context -- but blocking calls that wait idle on a lock or for I/O or for another operation are a bad idea.)
              – Miral
              4 hours ago








            2




            2




            @Miral You've used "call an async method from a sync method" in both possibilities.
            – Adrian Wragg
            19 hours ago




            @Miral You've used "call an async method from a sync method" in both possibilities.
            – Adrian Wragg
            19 hours ago












            @AdrianWragg So I did; my brain must have had a race condition. I'll fix it.
            – Miral
            4 hours ago




            @AdrianWragg So I did; my brain must have had a race condition. I'll fix it.
            – Miral
            4 hours ago












            It's the other way around; it's trivial to call an async method from a sync method, but it's impossible to call a sync method from an async method. (And where things completely fall apart is when someone tries to do the latter anyway, which can lead to deadlocks.) So if you had to pick one, async by default is the better choice. Unfortunately it's also the harder choice, because an async implementation can only call async methods.
            – Miral
            4 hours ago




            It's the other way around; it's trivial to call an async method from a sync method, but it's impossible to call a sync method from an async method. (And where things completely fall apart is when someone tries to do the latter anyway, which can lead to deadlocks.) So if you had to pick one, async by default is the better choice. Unfortunately it's also the harder choice, because an async implementation can only call async methods.
            – Miral
            4 hours ago












            (And by this I of course mean a blocking sync method. You can call something that makes a pure CPU-bound calculation synchronously from an async method -- although you should try to avoid doing it unless you know you're in a worker context rather than a UI context -- but blocking calls that wait idle on a lock or for I/O or for another operation are a bad idea.)
            – Miral
            4 hours ago




            (And by this I of course mean a blocking sync method. You can call something that makes a pure CPU-bound calculation synchronously from an async method -- although you should try to avoid doing it unless you know you're in a worker context rather than a UI context -- but blocking calls that wait idle on a lock or for I/O or for another operation are a bad idea.)
            – Miral
            4 hours ago










            corentinaltepe is a new contributor. Be nice, and check out our Code of Conduct.










            draft saved

            draft discarded


















            corentinaltepe is a new contributor. Be nice, and check out our Code of Conduct.













            corentinaltepe is a new contributor. Be nice, and check out our Code of Conduct.












            corentinaltepe is a new contributor. Be nice, and check out our Code of Conduct.
















            Thanks for contributing an answer to Software Engineering Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsoftwareengineering.stackexchange.com%2fquestions%2f382486%2farent-the-guidelines-of-async-await-usage-in-c-contradicting-the-concepts-of-g%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Ellipse (mathématiques)

            Quarter-circle Tiles

            Mont Emei