Is possible read half size of object happen in multi-thread?How to solves image processing cause camera io delay?How can one use multi threading in PHP applicationsMultithreaded thread-safe animation suggestions in c++Pthread condition variable unpredictable outcomeHow should I lock a wxMutex in one function and unlock it in another?On visual C++ how can I works on an array of images with threads (parallelism)OSX main queue from console applicationCorrectly using mutex in OpenCL-OpenCV-Realtime-Threads?Initialising OpenCV-VideoCapture-class in another multithreading classHow to use IFileOperation CopyItems for a destination ZIP filecomunication between threads using condition variables

Has JSON.serialize suppressApexObjectNulls ever worked?

Dedicated bike GPS computer over smartphone

Will users know a CardView is clickable

What is the theme of analysis?

Idiom for 'person who gets violent when drunk"

Why did Robert pick unworthy men for the White Cloaks?

I received a gift from my sister who just got back from

Approach sick days in feedback meeting

How effective would a full set of plate armor be against wild animals found in temperate regions (bears, snakes, wolves)?

Why did the Death Eaters wait to reopen the Chamber of Secrets?

Can I get a photo of an Ancient Arrow?

Is pointing finger in meeting consider bad?

Background for black and white chart

How can I find out about the game world without meta-influencing it?

What are the advantages of using TLRs to rangefinders?

Arrows inside a commutative diagram using tikzcd

Should I worry about having my credit pulled multiple times while car shopping?

Short story about psychologist analyzing demon

Is it ethical to cite a reviewer's papers even if they are rather irrelevant?

Difference between grep -R and -r

Is it possible to have battery technology that can't be duplicated?

Harley Davidson clattering noise from engine, backfire and failure to start

Placement of positioning lights on A320 winglets

What do I need to do, tax-wise, for a sudden windfall?



Is possible read half size of object happen in multi-thread?


How to solves image processing cause camera io delay?How can one use multi threading in PHP applicationsMultithreaded thread-safe animation suggestions in c++Pthread condition variable unpredictable outcomeHow should I lock a wxMutex in one function and unlock it in another?On visual C++ how can I works on an array of images with threads (parallelism)OSX main queue from console applicationCorrectly using mutex in OpenCL-OpenCV-Realtime-Threads?Initialising OpenCV-VideoCapture-class in another multithreading classHow to use IFileOperation CopyItems for a destination ZIP filecomunication between threads using condition variables






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;








-1















Having two thread, one product data, another one process data.
The data is not just an int or float but a complex object. In my case, it's an OpenCV Mat(an image).
If the first thread only created half-size of the image, and second thread read it, will get half size of the image? The image will be broken?



int main(int argc, char *argv[])

cv::Mat buffer;
cv::VideoCapture cap;
std::mutex mutex;
cap.open(0);
std::thread product([](cv::Mat& buffer, cv::VideoCapture cap, std::mutex& mutex)
while (true) // keep product the new image
cv::Mat tmp;
cap >> tmp;
//mutex.lock();
buffer = tmp.clone();
//mutex.unlock();

, std::ref(buffer), cap, std::ref(mutex));
product.detach();
int i;
while (true) // process in the main thread
//mutex.lock();
cv::Mat tmp = buffer;
//mutex.unlock();
if(!tmp.data)
std::cout<<"null"<<i++<<std::endl;
else
//std::cout<<"not null"<<std::endl;
cv::imshow("test", tmp);

if(cv::waitKey(30) >= 0) break;

return 0;



Do I need to add a mutex around write and read to make sure the image not be broken? Like this:



int main(int argc, char *argv[])

cv::Mat buffer;
cv::VideoCapture cap;
std::mutex mutex;
cap.open(0);
std::thread product([](cv::Mat& buffer, cv::VideoCapture cap, std::mutex& mutex)
while (true) // keep product the new image
cv::Mat tmp;
cap >> tmp;
mutex.lock();
buffer = tmp.clone();
mutex.unlock();

, std::ref(buffer), cap, std::ref(mutex));
product.detach();

while (true) // process in the main thread
mutex.lock();
cv::Mat tmp = buffer;
mutex.unlock();
if(!tmp.data)
std::cout<<"null"<<std::endl;
else
std::cout<<"not null"<<std::endl;
cv::imshow("test", tmp);



return 0;



This question related to How to solves image processing cause camera io delay?










share|improve this question






























    -1















    Having two thread, one product data, another one process data.
    The data is not just an int or float but a complex object. In my case, it's an OpenCV Mat(an image).
    If the first thread only created half-size of the image, and second thread read it, will get half size of the image? The image will be broken?



    int main(int argc, char *argv[])

    cv::Mat buffer;
    cv::VideoCapture cap;
    std::mutex mutex;
    cap.open(0);
    std::thread product([](cv::Mat& buffer, cv::VideoCapture cap, std::mutex& mutex)
    while (true) // keep product the new image
    cv::Mat tmp;
    cap >> tmp;
    //mutex.lock();
    buffer = tmp.clone();
    //mutex.unlock();

    , std::ref(buffer), cap, std::ref(mutex));
    product.detach();
    int i;
    while (true) // process in the main thread
    //mutex.lock();
    cv::Mat tmp = buffer;
    //mutex.unlock();
    if(!tmp.data)
    std::cout<<"null"<<i++<<std::endl;
    else
    //std::cout<<"not null"<<std::endl;
    cv::imshow("test", tmp);

    if(cv::waitKey(30) >= 0) break;

    return 0;



    Do I need to add a mutex around write and read to make sure the image not be broken? Like this:



    int main(int argc, char *argv[])

    cv::Mat buffer;
    cv::VideoCapture cap;
    std::mutex mutex;
    cap.open(0);
    std::thread product([](cv::Mat& buffer, cv::VideoCapture cap, std::mutex& mutex)
    while (true) // keep product the new image
    cv::Mat tmp;
    cap >> tmp;
    mutex.lock();
    buffer = tmp.clone();
    mutex.unlock();

    , std::ref(buffer), cap, std::ref(mutex));
    product.detach();

    while (true) // process in the main thread
    mutex.lock();
    cv::Mat tmp = buffer;
    mutex.unlock();
    if(!tmp.data)
    std::cout<<"null"<<std::endl;
    else
    std::cout<<"not null"<<std::endl;
    cv::imshow("test", tmp);



    return 0;



    This question related to How to solves image processing cause camera io delay?










    share|improve this question


























      -1












      -1








      -1








      Having two thread, one product data, another one process data.
      The data is not just an int or float but a complex object. In my case, it's an OpenCV Mat(an image).
      If the first thread only created half-size of the image, and second thread read it, will get half size of the image? The image will be broken?



      int main(int argc, char *argv[])

      cv::Mat buffer;
      cv::VideoCapture cap;
      std::mutex mutex;
      cap.open(0);
      std::thread product([](cv::Mat& buffer, cv::VideoCapture cap, std::mutex& mutex)
      while (true) // keep product the new image
      cv::Mat tmp;
      cap >> tmp;
      //mutex.lock();
      buffer = tmp.clone();
      //mutex.unlock();

      , std::ref(buffer), cap, std::ref(mutex));
      product.detach();
      int i;
      while (true) // process in the main thread
      //mutex.lock();
      cv::Mat tmp = buffer;
      //mutex.unlock();
      if(!tmp.data)
      std::cout<<"null"<<i++<<std::endl;
      else
      //std::cout<<"not null"<<std::endl;
      cv::imshow("test", tmp);

      if(cv::waitKey(30) >= 0) break;

      return 0;



      Do I need to add a mutex around write and read to make sure the image not be broken? Like this:



      int main(int argc, char *argv[])

      cv::Mat buffer;
      cv::VideoCapture cap;
      std::mutex mutex;
      cap.open(0);
      std::thread product([](cv::Mat& buffer, cv::VideoCapture cap, std::mutex& mutex)
      while (true) // keep product the new image
      cv::Mat tmp;
      cap >> tmp;
      mutex.lock();
      buffer = tmp.clone();
      mutex.unlock();

      , std::ref(buffer), cap, std::ref(mutex));
      product.detach();

      while (true) // process in the main thread
      mutex.lock();
      cv::Mat tmp = buffer;
      mutex.unlock();
      if(!tmp.data)
      std::cout<<"null"<<std::endl;
      else
      std::cout<<"not null"<<std::endl;
      cv::imshow("test", tmp);



      return 0;



      This question related to How to solves image processing cause camera io delay?










      share|improve this question
















      Having two thread, one product data, another one process data.
      The data is not just an int or float but a complex object. In my case, it's an OpenCV Mat(an image).
      If the first thread only created half-size of the image, and second thread read it, will get half size of the image? The image will be broken?



      int main(int argc, char *argv[])

      cv::Mat buffer;
      cv::VideoCapture cap;
      std::mutex mutex;
      cap.open(0);
      std::thread product([](cv::Mat& buffer, cv::VideoCapture cap, std::mutex& mutex)
      while (true) // keep product the new image
      cv::Mat tmp;
      cap >> tmp;
      //mutex.lock();
      buffer = tmp.clone();
      //mutex.unlock();

      , std::ref(buffer), cap, std::ref(mutex));
      product.detach();
      int i;
      while (true) // process in the main thread
      //mutex.lock();
      cv::Mat tmp = buffer;
      //mutex.unlock();
      if(!tmp.data)
      std::cout<<"null"<<i++<<std::endl;
      else
      //std::cout<<"not null"<<std::endl;
      cv::imshow("test", tmp);

      if(cv::waitKey(30) >= 0) break;

      return 0;



      Do I need to add a mutex around write and read to make sure the image not be broken? Like this:



      int main(int argc, char *argv[])

      cv::Mat buffer;
      cv::VideoCapture cap;
      std::mutex mutex;
      cap.open(0);
      std::thread product([](cv::Mat& buffer, cv::VideoCapture cap, std::mutex& mutex)
      while (true) // keep product the new image
      cv::Mat tmp;
      cap >> tmp;
      mutex.lock();
      buffer = tmp.clone();
      mutex.unlock();

      , std::ref(buffer), cap, std::ref(mutex));
      product.detach();

      while (true) // process in the main thread
      mutex.lock();
      cv::Mat tmp = buffer;
      mutex.unlock();
      if(!tmp.data)
      std::cout<<"null"<<std::endl;
      else
      std::cout<<"not null"<<std::endl;
      cv::imshow("test", tmp);



      return 0;



      This question related to How to solves image processing cause camera io delay?







      c++ multithreading opencv parallel-processing thread-safety






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Mar 25 at 4:48







      Jiu

















      asked Mar 25 at 1:42









      JiuJiu

      1,79721536




      1,79721536






















          1 Answer
          1






          active

          oldest

          votes


















          1














          As soon as you have one thread modifying an object while another thread potentially accesses the value of that same object concurrently, you have a race condition and behavior is undefined. Yes, that can happen. And, since we're talking about an object like an entire image buffer here, almost certainly will happen. And yes, you will need to use proper synchronization to prevent it from happening.



          From your description, it would seem that you basically have a situation here where one thread is producing some image and another thread has to wait for the image to be ready. In this case, the first question that you should ask yourself is: if the second thread cannot start its work before the first thread has completed its work, then what exactly are you gaining by using a second thread here? If there is still enough work that both threads can do in parallel for this all to make sense, then you will most likely want to use not just a simple mutex here, but more something like, e.g., a condition variable or a barrier…






          share|improve this answer























          • Thanks, I updated the question. Could you please take a look.

            – Jiu
            Mar 25 at 3:06











          • Race conditions are unavoidable when you (usefully) use any synchronisation primitive like a mutex: which thread get to lock a mutex is unpredictable.

            – curiousguy
            Mar 25 at 15:23











          • Research term - Double buffering (in computer graphics.)

            – 2785528
            Mar 27 at 1:49











          Your Answer






          StackExchange.ifUsing("editor", function ()
          StackExchange.using("externalEditor", function ()
          StackExchange.using("snippets", function ()
          StackExchange.snippets.init();
          );
          );
          , "code-snippets");

          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "1"
          ;
          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',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          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
          );



          );













          draft saved

          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55330314%2fis-possible-read-half-size-of-object-happen-in-multi-thread%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          1














          As soon as you have one thread modifying an object while another thread potentially accesses the value of that same object concurrently, you have a race condition and behavior is undefined. Yes, that can happen. And, since we're talking about an object like an entire image buffer here, almost certainly will happen. And yes, you will need to use proper synchronization to prevent it from happening.



          From your description, it would seem that you basically have a situation here where one thread is producing some image and another thread has to wait for the image to be ready. In this case, the first question that you should ask yourself is: if the second thread cannot start its work before the first thread has completed its work, then what exactly are you gaining by using a second thread here? If there is still enough work that both threads can do in parallel for this all to make sense, then you will most likely want to use not just a simple mutex here, but more something like, e.g., a condition variable or a barrier…






          share|improve this answer























          • Thanks, I updated the question. Could you please take a look.

            – Jiu
            Mar 25 at 3:06











          • Race conditions are unavoidable when you (usefully) use any synchronisation primitive like a mutex: which thread get to lock a mutex is unpredictable.

            – curiousguy
            Mar 25 at 15:23











          • Research term - Double buffering (in computer graphics.)

            – 2785528
            Mar 27 at 1:49















          1














          As soon as you have one thread modifying an object while another thread potentially accesses the value of that same object concurrently, you have a race condition and behavior is undefined. Yes, that can happen. And, since we're talking about an object like an entire image buffer here, almost certainly will happen. And yes, you will need to use proper synchronization to prevent it from happening.



          From your description, it would seem that you basically have a situation here where one thread is producing some image and another thread has to wait for the image to be ready. In this case, the first question that you should ask yourself is: if the second thread cannot start its work before the first thread has completed its work, then what exactly are you gaining by using a second thread here? If there is still enough work that both threads can do in parallel for this all to make sense, then you will most likely want to use not just a simple mutex here, but more something like, e.g., a condition variable or a barrier…






          share|improve this answer























          • Thanks, I updated the question. Could you please take a look.

            – Jiu
            Mar 25 at 3:06











          • Race conditions are unavoidable when you (usefully) use any synchronisation primitive like a mutex: which thread get to lock a mutex is unpredictable.

            – curiousguy
            Mar 25 at 15:23











          • Research term - Double buffering (in computer graphics.)

            – 2785528
            Mar 27 at 1:49













          1












          1








          1







          As soon as you have one thread modifying an object while another thread potentially accesses the value of that same object concurrently, you have a race condition and behavior is undefined. Yes, that can happen. And, since we're talking about an object like an entire image buffer here, almost certainly will happen. And yes, you will need to use proper synchronization to prevent it from happening.



          From your description, it would seem that you basically have a situation here where one thread is producing some image and another thread has to wait for the image to be ready. In this case, the first question that you should ask yourself is: if the second thread cannot start its work before the first thread has completed its work, then what exactly are you gaining by using a second thread here? If there is still enough work that both threads can do in parallel for this all to make sense, then you will most likely want to use not just a simple mutex here, but more something like, e.g., a condition variable or a barrier…






          share|improve this answer













          As soon as you have one thread modifying an object while another thread potentially accesses the value of that same object concurrently, you have a race condition and behavior is undefined. Yes, that can happen. And, since we're talking about an object like an entire image buffer here, almost certainly will happen. And yes, you will need to use proper synchronization to prevent it from happening.



          From your description, it would seem that you basically have a situation here where one thread is producing some image and another thread has to wait for the image to be ready. In this case, the first question that you should ask yourself is: if the second thread cannot start its work before the first thread has completed its work, then what exactly are you gaining by using a second thread here? If there is still enough work that both threads can do in parallel for this all to make sense, then you will most likely want to use not just a simple mutex here, but more something like, e.g., a condition variable or a barrier…







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Mar 25 at 1:55









          Michael KenzelMichael Kenzel

          10.7k11926




          10.7k11926












          • Thanks, I updated the question. Could you please take a look.

            – Jiu
            Mar 25 at 3:06











          • Race conditions are unavoidable when you (usefully) use any synchronisation primitive like a mutex: which thread get to lock a mutex is unpredictable.

            – curiousguy
            Mar 25 at 15:23











          • Research term - Double buffering (in computer graphics.)

            – 2785528
            Mar 27 at 1:49

















          • Thanks, I updated the question. Could you please take a look.

            – Jiu
            Mar 25 at 3:06











          • Race conditions are unavoidable when you (usefully) use any synchronisation primitive like a mutex: which thread get to lock a mutex is unpredictable.

            – curiousguy
            Mar 25 at 15:23











          • Research term - Double buffering (in computer graphics.)

            – 2785528
            Mar 27 at 1:49
















          Thanks, I updated the question. Could you please take a look.

          – Jiu
          Mar 25 at 3:06





          Thanks, I updated the question. Could you please take a look.

          – Jiu
          Mar 25 at 3:06













          Race conditions are unavoidable when you (usefully) use any synchronisation primitive like a mutex: which thread get to lock a mutex is unpredictable.

          – curiousguy
          Mar 25 at 15:23





          Race conditions are unavoidable when you (usefully) use any synchronisation primitive like a mutex: which thread get to lock a mutex is unpredictable.

          – curiousguy
          Mar 25 at 15:23













          Research term - Double buffering (in computer graphics.)

          – 2785528
          Mar 27 at 1:49





          Research term - Double buffering (in computer graphics.)

          – 2785528
          Mar 27 at 1:49



















          draft saved

          draft discarded
















































          Thanks for contributing an answer to Stack Overflow!


          • 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%2fstackoverflow.com%2fquestions%2f55330314%2fis-possible-read-half-size-of-object-happen-in-multi-thread%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

          Kamusi Yaliyomo Aina za kamusi | Muundo wa kamusi | Faida za kamusi | Dhima ya picha katika kamusi | Marejeo | Tazama pia | Viungo vya nje | UrambazajiKuhusu kamusiGo-SwahiliWiki-KamusiKamusi ya Kiswahili na Kiingerezakuihariri na kuongeza habari

          SQL error code 1064 with creating Laravel foreign keysForeign key constraints: When to use ON UPDATE and ON DELETEDropping column with foreign key Laravel error: General error: 1025 Error on renameLaravel SQL Can't create tableLaravel Migration foreign key errorLaravel php artisan migrate:refresh giving a syntax errorSQLSTATE[42S01]: Base table or view already exists or Base table or view already exists: 1050 Tableerror in migrating laravel file to xampp serverSyntax error or access violation: 1064:syntax to use near 'unsigned not null, modelName varchar(191) not null, title varchar(191) not nLaravel cannot create new table field in mysqlLaravel 5.7:Last migration creates table but is not registered in the migration table

          은진 송씨 목차 역사 본관 분파 인물 조선 왕실과의 인척 관계 집성촌 항렬자 인구 같이 보기 각주 둘러보기 메뉴은진 송씨세종실록 149권, 지리지 충청도 공주목 은진현