LINUX.ORG.RU

Создание фонового треда на время жизни класса

 


0

2

Идея примерно такая. Есть некоторый класс A в котором есть некоторая струтура данных, допустим мапа. Класс имеет публичные методы работы с этой мапой. Но нам допустим надо запустить фоновый поток который будет в бесконечном цикле проверять, ну допустим насколько запись в мапе стара и удалять ее если надо. Тред должен завершиться вместе с уничтожением класса без ругани и эксепшенов.

Придмал такое решение. Подскажите, если тут подводные камни, или оно нормальное? Естественно, потом туда надо добавить еще мьютексы. Но меня сейчас больше интересует создание и управление этим фоновым тредом

#include <thread>
#include <memory>
#include <map>
#include <iostream>
typedef  std::map<std::string,std::string> MyMap;

class A
{
private:
  class Thread
  {
  private:
    bool flag;
    MyMap& my_map_inst;
    std::thread thr;
  public:

    void funct()
    {
      while (flag) {
        std::cout << "ooo" << std::endl;
      }
      std::cout << "fin" << std::endl;
    }

    Thread(MyMap& m) : flag(true), my_map_inst(m), thr(std::bind(&Thread::funct,this))
    {
    }

    void final()
    {
      flag = false;
      thr.join();
    }

  };

  MyMap my_map_inst;

  Thread thread_i;
public:
  A() : thread_i(my_map_inst)
  {

  }

  ~A()
  {
    thread_i.final();
  }

};

int main()
{

  {
  A a;

  }
  std::cout << "111" << std::endl;

  int i;
  std::cin >> i;
  return 0;
}

По идее проблем быть не должно. Стандарт вроде гарантирует создание мапы до создания объекта треда и инициализацию контрольного флага (flag) до запуска треда. Может тут есть еще какие подводные камни?

★★★★★

Последнее исправление: Dudraug (всего исправлений: 3)

Ответ на: комментарий от UVV

Может быть съезжу (дурное дело не хитрое - байерн тикет в зубы и там).

Если поеду то 23 или 25, но зависит от других вещей.

invy ★★★★★
()
Ответ на: комментарий от invy

байерн тикет в зубы и там

Чё стоит, если не секрет?

Если поеду то 23 или 25, но зависит от других вещей.

Мы толпой едем. 24-го к обеду там, 25-го после обеда назад.

UVV ★★★★★
()
Ответ на: комментарий от UVV

Чё стоит, если не секрет?

Где-то 25.

Мы толпой едем. 24-го к обеду там, 25-го после обеда назад.

Может и 24-го после обеда буду. Тоже вариант, но it depends :)

В общем admission ticket я сделал, там посмотрим :)

invy ★★★★★
()
Ответ на: комментарий от invy

Во-первых, бизи-whatever тут только для примера, об этом явно написано. Во-вторых, это не бизивейтинг, потому что в цикле предполагается какая-то работа. Во-третьих, ещё раз: прочитай сначала статью - там вообще-то про ядерное API. В-червёртых, написана там на самом деле ерунда, потому что статья претендует на универсальность, в то время как отдавать процессор нужно далеко не во всех случаях. В-пятых, никакого обоснования вредности volatile bool там нету, хоть ты тресни.

Нет, крупица истины в твоей претензии всё-таки есть - правильнее было бы использовать std::atomic_bool или std::atomic_flag. Но я специально подчеркнул что это лишь пример, который показывает что с std::thread можно работать проще, который должен быть дописан с использованием condition_variable, а в пример вводить лишние сущности типа atomic не имеет смысла, и убрать volatile гораздо нагляднее чем переделывать atomic.

slovazap ★★★★★
()
Ответ на: комментарий от invy

volatile != atomic

А с этим никто не спорит.

volatile не пригодно для мультитрединга

А вот это ложь. Начнём с того что bool совершенно не нужно быть atomic.

slovazap ★★★★★
()
Ответ на: комментарий от vvviperrr

уж сколько раз твердили миру

Кодомакаки могут твердить что угодно кому угодно. volatile для флажка ок.

kawaii_neko ★★★★
()
Ответ на: комментарий от slovazap

А вот это ложь. Начнём с того что bool совершенно не нужно быть atomic.

Стандарт говорит, что это - data race и следовательно UD.

The execution of a program contains a data race if it contains two conflicting actions in different threads, at least one of which is not atomic, and neither happens before the other. Any such data race results in undefined behavior.

invy ★★★★★
()
Ответ на: комментарий от kawaii_neko

Да, самый настоящий.

Я могу еще на доку сослаться... да блин тысячи мест.

http://en.cppreference.com/w/cpp/language/cv

volatile object - an object whose type is volatile-qualified, or a subobject of a volatile object, or a mutable subobject of a const-volatile object. Every access (read or write operation, member function call, etc.) on the volatile object is treated as a visible side-effect for the purposes of optimization (that is, within a single thread of execution, volatile accesses cannot be reordered or optimized out. This makes volatile objects suitable for communication with a signal handler, but not with another thread of execution, see std::memory_order). Any attempt to refer to a volatile object through a non-volatile glvalue (e.g. through a reference or pointer to non-volatile type) results in undefined behavior.

http://en.cppreference.com/w/cpp/atomic/memory_order

Relationship with volatile Within a thread of execution, accesses (reads and writes) to all volatile objects are guaranteed to not be reordered relative to each other, but this order is not guaranteed to be observed by another thread, since volatile access does not establish inter-thread synchronization. In addition, volatile accesses are not atomic (concurrent read and write is a data race) and do not order memory (non-volatile memory accesses may be freely reordered around the volatile access). One notable exception is Visual Studio, where, with default settings, every volatile write has release semantics and every volatile read has acquire semantics (MSDN), and thus volatiles may be used for inter-thread synchronization. Standard volatile semantics are not applicable to multithreaded programming, although they are sufficient for e.g. communication with a std::signal handler.

Так что, фанаты volatile для мультитрединга - брысь на винфак :D

invy ★★★★★
()
Последнее исправление: invy (всего исправлений: 2)
Ответ на: комментарий от invy

Нет, ссылаться ты можешь только на стандарт, и твоей цитаты выше там нет в помине firefox криво ищет по pdf. Но ты таки прав.

Two expression evaluations conflict if one of them modifies a memory location (1.7) and the other one accesses or modifies the same memory location.

The execution of a program contains a data race if it contains two potentially concurrent conflicting actions, at least one of which is not atomic, and neither happens before the other, except for the special case for signal handlers described below. Any such data race results in undefined behavior.

Ok, значит пусть будет std::atomic.

slovazap ★★★★★
()
Последнее исправление: slovazap (всего исправлений: 1)
Ответ на: комментарий от slovazap

Ok, значит пусть будет std::atomic.

Ур-ра! Он разрешил!

i-rinat ★★★★★
()
Ответ на: комментарий от invy

Чё-то я с датами напутал, sorry. Мы 23-го едем, а 24-го после обеда назад. В мыло мне стукни, если чо..

UVV ★★★★★
()
Ответ на: комментарий от invy

фанаты volatile для мультитрединга

Ок, но справедливости ради хочу заметить, что на volatile + __sync_* дофига всего написано.

kawaii_neko ★★★★
()
Ответ на: комментарий от Dudraug

Время отклика чтения/записи увеличивается.

т.е. после того как

Естественно, потом туда надо добавить еще мьютексы.

чтение/запись у тебя не будет ждать завершения порции работы нового треда?

anonymous
()
Ответ на: комментарий от anonymous

чтение/запись у тебя не будет ждать завершения порции работы нового треда?

Откуда вы лезете. Тред переиодично запускаться будет. Его влияние на работу записи/поиска будет минимальным. Это в любом случае лучше, чем чистить при каждой вставке как некоторые предлагают.

Dudraug ★★★★★
() автор топика
Ответ на: комментарий от Dudraug

Решения я вижу тут только два: 1) запустить бэкграунд тред, который будет чистить ее в n секунд; 2) обходить мапу при поиски/добавление и удалять не нужное. По мне так первый подход намного лучше.

Можно еще создать вторую мапу, где ключом будет этот твой вторичный критерий, а значением - ключ основной мапы например. Нэ?

anonymous
()
Ответ на: комментарий от invy

и где здесь написано что-то отдельно про примитивные типы данных? здесь речь про объекты вообще, что не релевантно обсуждаемому коду.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.