C# Channels Explained (System.Threading.Channels)

Поділитися
Вставка
  • Опубліковано 24 гру 2024

КОМЕНТАРІ • 111

  • @GebzNotJebz
    @GebzNotJebz Рік тому +2

    The amount of effort i spent trying to learn this elsewhere.. I'm trying to build an external API for an application that i work on, and although i'm not very experienced in c#, this is extremely helpful. Thanks loads!!

  • @dbassett74
    @dbassett74 4 роки тому +14

    Man, i love your channel, no pun intended! I'll be donating soon.

  • @sandman1OO
    @sandman1OO 4 роки тому +8

    The best c# tutorials I`ve ever seen!

    • @RawCoding
      @RawCoding  4 роки тому

      Thank you! Means a lot :)

  • @VinuP2023
    @VinuP2023 4 роки тому +20

    Thank you for your time and efforts. You are definitely very underrated bro. You are amazing teacher.
    Can you pls create more C# advanced videos?

  • @HELLNAWW
    @HELLNAWW 11 місяців тому +1

    OMG Raw Coding I've watched so many of your videos but I have no idea how to do that on my own.

  • @thishandleistaken
    @thishandleistaken 4 роки тому +2

    Thank you! Never heard about channels. Glad I found your channel.

  • @ahmerkhan2676
    @ahmerkhan2676 4 роки тому +1

    You are underrated man! Keep uploading

  • @LucasMarinoElementh
    @LucasMarinoElementh 4 роки тому +4

    Thank you very much, I was looking forward to learn more about channels!

    • @RawCoding
      @RawCoding  4 роки тому

      Hope you learned a lot :)

  • @ChronoWrinkle
    @ChronoWrinkle 3 роки тому +1

    every interesting topic leads me to this channel, amazing and well done!

  • @IgorfariasSk8
    @IgorfariasSk8 3 роки тому +1

    Amazing video!! I can understand channels now! Thank you!

  • @mohamedanas8937
    @mohamedanas8937 2 роки тому +1

    Awesome Tutorial Bro...Subscribed😉

  • @sigma_z
    @sigma_z 4 роки тому

    Reactive Extensions is gonna be more flexible. IObserveable, IObserver, Subject

  • @fabrizziocht
    @fabrizziocht 3 роки тому +1

    Great tutorial, thank you so much! :D

    • @RawCoding
      @RawCoding  3 роки тому

      Thank you for watching

  • @paulinhocmc
    @paulinhocmc 4 роки тому +1

    Very good video! 👏👏
    I love your videos and the way you explain!
    Hello from Brazil! ✌️

  • @ivanvincent7534
    @ivanvincent7534 3 роки тому +1

    Appreciate the content. Your final comment about using channels with micro services sounds interesting. Have you demonstrated this in any of your other videos?

    • @RawCoding
      @RawCoding  3 роки тому

      Nope, just a note, the “channels” in the microservices scenario would have to be their own services - like RabbitMQ, Google PubSub, Kafka, Reddis PubSub etc...

    • @ivanvincent7534
      @ivanvincent7534 3 роки тому +1

      Thanks for the response. I understand now your meaning in the context of microservices. I have one more follow up question... Why use a Channel over something like a BlockingCollection? I believe the primary difference is that Channels offer asynchronous reading and writing but not sure of the benefits of async given that the underlying queue would be memory bound?

    • @RawCoding
      @RawCoding  3 роки тому +1

      Async saftey means that if 2 threads try to read from the same queue nothing blocks. Blocking means while thread 1 is reading, thread 2 is sitting there waiting instead of doing something else, then imagine you have 96 cpu machine and 192 threads or however many sitting there waiting

    • @ivanvincent7534
      @ivanvincent7534 3 роки тому +1

      Thanks for your response. So the non blocking nature of channels is a big plus for performance. My understanding was that the usage of async await was for IO bound workloads but it seems that it is also applicable to structures that are stored on the heap in memory.

    • @RawCoding
      @RawCoding  3 роки тому +1

      Not quite, the whole reason the Channel exists is because we have multi threaded environments, so communication between threads can be treated as IO. There’s nothing to offload to if there’s only 1 thread, so no need for channels.

  • @learnwithcode4211
    @learnwithcode4211 3 роки тому +1

    Thanks a lot for these advanced videos. I learned a lot Thanks again :)

    • @RawCoding
      @RawCoding  3 роки тому

      Thank you for watching

  • @sanjayi6245
    @sanjayi6245 4 роки тому +1

    Continue the good work.

  • @bertolimauro
    @bertolimauro 4 роки тому +6

    Tks, very practical way of explaining concepts, I like it a lot. One question about the video: at the end you were saying about microservices... can channels be shared between different processes? Or it was an example of channels as a concept but using persistent queues (rabbitmq, azure queue, etc)?

    • @RawCoding
      @RawCoding  4 роки тому +1

      Channels can be shared between processes and they can be shared between instances if they are instances as well (by instance I mean a running service on a vm box) publisher/subscriber queues are essentially channels

    • @bertolimauro
      @bertolimauro 4 роки тому +3

      @@RawCoding how can you share a System.Threading.Channels instance between processes? I don't find any example doing that, it looks more a in-process thing

    • @RawCoding
      @RawCoding  4 роки тому +5

      @@bertolimauro Ah yes pardon, if you have 2 seperate applications you can't channel between them. I thought we were talking more about threads on different processors.

    • @mohammadhosseinbasiri494
      @mohammadhosseinbasiri494 11 місяців тому

      I think rabbitmq and azure queue + microservice is very similar to this channel + background service so why should we send a queue to another queue?

  • @Jack13Ripper
    @Jack13Ripper 2 роки тому +1

    Que buen video man! Muchas gracias! Sigue tu buen trabajo.

  • @juhairahamed5342
    @juhairahamed5342 Рік тому +1

    Good Explanation bro

  • @cuno2712
    @cuno2712 4 роки тому +1

    Thanks for "Explain like I'm five" stuff like this.

    • @RawCoding
      @RawCoding  4 роки тому

      Thank you for watching:)

  • @swastikprince164
    @swastikprince164 3 роки тому +1

    Man.. i would like to learn code like you.. really smart.

  • @mattaku9430
    @mattaku9430 Рік тому

    Very good tutorial

  • @farzinfaghirnavaz1027
    @farzinfaghirnavaz1027 4 роки тому +1

    Thanks, man, you are the best

  • @milost3901
    @milost3901 2 роки тому +3

    Good stuff. I got one question: in your custom implementation of channel, why did you need SemaphoreSlim (ie. await _flag.WaitAsync(); in Read() method) if we are using ConcurrentQueue which is already thread-safe?

    • @RawCoding
      @RawCoding  2 роки тому +2

      Eh can’t remember

    • @Lammot
      @Lammot 2 роки тому +4

      It's not for managing thread safety, it's for consumer to be able to await Dequeue (_flag.WaitAsync under the hood) and guarantee there will be something there on callback. Otherwise it would have to thrash while(true) { Dequeue() }
      Although, I think there's a bug with this approach when you have more than 1 consumer. Technically, both of them can await Dequeue operation, but there migth only be 1 message left. So the one consumer, that got the message will execute it's code, attempt to while and exit. While the other one will be stuck awaiting Dequeue without the ability to check if Procuder is completed.

  • @АртемАрте-г5х
    @АртемАрте-г5х 11 місяців тому +1

    Hi. You said, that channels helped to solve problem of the disposed data base in the last part of the video. But I didn't see see how thay affected it. Really what I saw is a usage of the ServiceProvider as global instance injected into background service and resolved dependency with a scope. So, Channels didn't affect on this part. Is that true, or I've lost smth ?

    • @RawCoding
      @RawCoding  11 місяців тому

      Yeas because the background service creates its own scope, if you try to do fire and forget in a controller (for example) and attempt to retain a reference to the database - when the request finishes it will dispose of the dbcontext, crashing the fire amd forget call

  • @igorilyichyov6414
    @igorilyichyov6414 2 роки тому

    Thanks a lot!👍👍👍

  • @akshay_zz
    @akshay_zz 3 роки тому

    Great explanation

    • @RawCoding
      @RawCoding  3 роки тому

      Cheers

    • @akshay_zz
      @akshay_zz 3 роки тому

      ​@@RawCoding One small doubt was there. You said injecting scoped database to a singleton class can cause problem. So do we need to inject other services also same way. Or what's the logic behind that.

    • @RawCoding
      @RawCoding  3 роки тому

      Non singleton services in a singleton should be managed through IServiceProvider

  • @pschrall
    @pschrall 4 роки тому +1

    Perfect!

  • @rambond7539
    @rambond7539 3 роки тому +1

    Thank you very useful, how can client get back the notification? For e.g., client send a request to process something which can be done through channel request and processed by background service but how do client get back the notification in asyncrhouse?

    • @RawCoding
      @RawCoding  3 роки тому +1

      This is a producer consumer problem so client shouldn’t really be notified if the msg has been processed. However you can do so with another channel

  • @冷面包
    @冷面包 4 роки тому +2

    Can I just use ConcurrentQueue and keep enqueue and dequeue in two different thread?

    • @RawCoding
      @RawCoding  4 роки тому

      Yes as long as the concurrentQueue that is supplied to the two threads is the same

    • @冷面包
      @冷面包 4 роки тому

      @@RawCoding OK thanks

  • @takukasai7116
    @takukasai7116 4 роки тому +1

    Thank you very much, nice video.
    How do I know if the channel is executing tasks? thus avoiding sending the same message that has not yet been read?

    • @RawCoding
      @RawCoding  4 роки тому

      Channel never executes anything. Channel is like a tube that passes messages around.
      If you still think you need to check if the message has been received and processes:
      - send an acknowledgment message from the receiver/processor
      If you don't want to send duplicates
      - use a cache

  • @giorgititvinidze4199
    @giorgititvinidze4199 2 роки тому +1

    Thank you very much.
    In the fire and forget solution we can use IServiceProvider to get services and there will be no more errors. Is this solution acceptable?

    • @RawCoding
      @RawCoding  2 роки тому

      As long as you don’t put bugs in there no more errors

  • @jexes2020
    @jexes2020 4 роки тому +1

    nice! what about displaying the notification on a web page like a popup or something instead of sending an email?
    I don't think that a backgroud will be able to achieve this behaviour.

    • @RawCoding
      @RawCoding  4 роки тому

      We have the database service there we can get all the information we need. We can then use smtp, http, signalr to send notifications and anything else that you can think of. As well as save stuff in the database. In larger systems you would extract this in to a separate service and connect them via a pub/sub channel.

  • @rezarezash
    @rezarezash 4 роки тому +1

    Thank you very much. Very well explained and useful. How can I have two or more producers pushing/distributing for example 10 numbers to the consumers? instead of each generates 10 separate numbers.

    • @RawCoding
      @RawCoding  4 роки тому +1

      I'd reccomend reading through this deniskyashif.com/2019/12/08/csharp-channels-part-1/ until I get around to making a part 2 for Channels, won't be after next week :)

  • @ilkereksioglu1715
    @ilkereksioglu1715 2 місяці тому

    Why does services get deleted at 4:30? Just bcs of DI? GC should leave it be as it is referenced as I know. Also, love your work:)

  • @jeffmair
    @jeffmair 3 роки тому

    Thanks very much, this video was exactly what I needed. I'm relatively new to .net core & background services. I have a background service that just periodically checks a database table for a request. The DB table is essentially the channel, but this is a more elegant solution. At least, if I don't need to retain information about my requests. On that note, do you have any suggested alternative to using a DB table when I want to periodically check in on the status of the request that was made to the background service? Or DB table is fine/typical? I suppose I could keep knowledge of those requests in a singleton memory cache... any thoughts would be appreciated.

    • @RawCoding
      @RawCoding  3 роки тому +1

      Depends on what you need. DB is fine, if you use in memory cache you could struggle with scalability and consistency after restarts - 2 instances making these background checks might not be what you want.

  • @avindev
    @avindev 4 роки тому +1

    Do you have a discord channel too? Great stuff man. That k you for doing this.

    • @RawCoding
      @RawCoding  4 роки тому

      Thank you for watching

  • @nik5167
    @nik5167 2 роки тому

    Merci! J'ai deja qq appli ou je pense pouvoir utiliser les Channels pour rendre le API plus snappy et ainsi avoir meilleur UX

  • @brightshadow9480
    @brightshadow9480 4 роки тому +1

    Great video, but your volume levels are on the floor. I'd recommend upping your gain or doing some amplification in post.

    • @RawCoding
      @RawCoding  4 роки тому

      Yeah sorry it was at a time I got a new mic had no clue what I was doing

  • @markyanthonylaredo2614
    @markyanthonylaredo2614 4 роки тому +1

    ❤❤

  • @MohamedOmar-zw2bq
    @MohamedOmar-zw2bq 9 місяців тому

    Awesome video, but volume is too low.
    And what if I want to create multiple channels??

  • @KleinKwakuFHouzin
    @KleinKwakuFHouzin 4 роки тому +1

    Good video

  • @clearlyunwell
    @clearlyunwell 3 роки тому +1

    👍🏽

  • @gijduvon6379
    @gijduvon6379 3 роки тому

    What is the difference between using channels and using rabbit then?

    • @RawCoding
      @RawCoding  3 роки тому +1

      RabbitMQ is a hosted service for distributed systems

    • @gijduvon6379
      @gijduvon6379 3 роки тому

      @@RawCoding thank you for your answers! May I ask ... what about limitations of this channels thing? Can I use it for high loaded controller actions?

    • @RawCoding
      @RawCoding  3 роки тому

      The limit is the memory, if you are putting more messages on the queue than you can process then eventually you’ll run out of memory

  • @ebubekircagrsen7824
    @ebubekircagrsen7824 3 роки тому

    Your content is great but you need to volume up a little. Thank you

  • @leknyzma
    @leknyzma 2 роки тому

    breaking those 666 likes

  • @delysid604
    @delysid604 4 роки тому +1

    Put ur volume slightly higher bro. Hard to hear this vid

  • @jasonzuvela
    @jasonzuvela Рік тому

    Audio is way too quiet

  • @HELLNAWW
    @HELLNAWW 11 місяців тому

    Your always use so much built in stuff that I didn't know existed... It's like every line has different code that's unrelated