Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Non-Reentrant Class Use In Multithreaded Program
Forum Updated to NodeBB v4.3 + New Features

Non-Reentrant Class Use In Multithreaded Program

Scheduled Pinned Locked Moved Solved General and Desktop
64 Posts 6 Posters 19.6k Views 4 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • C Crag_Hack

    But I need to be able to stop the worker thread from the gui thread, not just when the program is scanning files but also when it is copying files, using the same cancel condition as created by clicking the cancel button in the gui thread. All the logic is handled in the worker thread both scanning, volume shadow copy service, file copying and everything. All of these operations need to be cancelled if desired. The worker thread remains alive it just gets reused for each backup that is performed. I did just find a workaround as per your suggestion got my creative juices flowing... I can check the std::atomic_bool cancel variable in the CopyFIleEx progress callback function and if it is true then return PROGRESS_CANCEL. Can you think of another way to do this though? Just curious.

    kshegunovK Offline
    kshegunovK Offline
    kshegunov
    Moderators
    wrote on last edited by
    #61

    @Crag_Hack said in Non-Reentrant Class Use In Multithreaded Program:

    I can check the std::atomic_bool cancel variable in the CopyFIleEx progress callback function and if it is true then return PROGRESS_CANCEL. Can you think of another way to do this though?

    This sounds like a decent plan to me.

    Read and abide by the Qt Code of Conduct

    1 Reply Last reply
    0
    • C Offline
      C Offline
      Crag_Hack
      wrote on last edited by Crag_Hack
      #62

      Will this code maintain the atomicity of the cancel variable? And should I declare cancel volatile? I'm guessing std:atomic_bool will make that unncecessary...

      class Worker : public QObject
      {
          bool getStop() { return cancel; }
          volatile std::atomic_bool cancel;
      ...
      DWORD Worker::copyProgress(LARGE_INTEGER totalSize, LARGE_INTEGER totalTransferred, LARGE_INTEGER, LARGE_INTEGER, DWORD, DWORD, HANDLE, HANDLE, LPVOID data)
      {
          Worker *worker = static_cast<Worker *>(data);
          if (worker->getStop())
              return PROGRESS_CANCEL;
      
      kshegunovK 1 Reply Last reply
      0
      • C Crag_Hack

        Will this code maintain the atomicity of the cancel variable? And should I declare cancel volatile? I'm guessing std:atomic_bool will make that unncecessary...

        class Worker : public QObject
        {
            bool getStop() { return cancel; }
            volatile std::atomic_bool cancel;
        ...
        DWORD Worker::copyProgress(LARGE_INTEGER totalSize, LARGE_INTEGER totalTransferred, LARGE_INTEGER, LARGE_INTEGER, DWORD, DWORD, HANDLE, HANDLE, LPVOID data)
        {
            Worker *worker = static_cast<Worker *>(data);
            if (worker->getStop())
                return PROGRESS_CANCEL;
        
        kshegunovK Offline
        kshegunovK Offline
        kshegunov
        Moderators
        wrote on last edited by kshegunov
        #63

        @Crag_Hack said in Non-Reentrant Class Use In Multithreaded Program:

        Will this code maintain the atomicity of the cancel variable?

        Yes, of course.

        And should I declare cancel volatile?

        No, no reason to do that. Forget volatile, especially if you're not intimately familiar with what it does. It's very special and here there is no a proper reason to use it.

        I'm guessing std:atomic_bool will make that unncecessary...

        That is correct. volatile means something quite different anyway, it doesn't provide atomicity at all.

        Read and abide by the Qt Code of Conduct

        1 Reply Last reply
        1
        • C Offline
          C Offline
          Crag_Hack
          wrote on last edited by
          #64

          Thanks! Almost time to go live!

          1 Reply Last reply
          0

          • Login

          • Login or register to search.
          • First post
            Last post
          0
          • Categories
          • Recent
          • Tags
          • Popular
          • Users
          • Groups
          • Search
          • Get Qt Extensions
          • Unsolved