Почему необходимо передавать указатель this в качестве аргумента arg в pthread_create
Моя среда — C ++ для Linux-Xenomai на ARM gnueabi. После успешного создания нового pthread я обнаружил, что экземпляр класса находится вне области видимости потока. При доступе к объектам экземпляра класса, переменным, структурам и т. Д. Из потока возвращались произвольные значения и часто «ошибка сегментации».
Потратив много дней на поиск решения в сети, я сделал предположение и попытался использовать указатель this в качестве аргумента для pthread_create. И вуаля! Экземпляр класса стал видимым для потока. Вопрос почему?
void*(*server_listener_fptr)(void*); // declare the function ptr
server_listener_fptr = reinterpret_cast<void*(*)(void*)>(&UDP_ClientServer::server_listener);
iret = pthread_create(&s_thread, NULL, server_listener_fptr, this);
Решение
Существует простая причина, по которой это эффективно запускает экземпляр класса как независимый поток родительского процесса. Журнал отладочного выполнения ниже проливает некоторый свет на ситуацию. Вводится метод :: init () экземпляра класса UDP_ClientServer с последующим созданием потока :: server_listener (void *), который является методом класса экземпляра класса UDP_ClientServer. Метод :: init (), который породил поток, затем завершается как UDP_ClientServer :: init () exit …, за которым следует метод экземпляра класса :: server_listener (void *), объявляющий себя потоком, как в UDP_ClientServer :: запись server_listener (void *) ….
# ./xeno_pruss 37 -INOAUTOENA -FREQ 100
-> -IRQ 37
-> -I_NOAUTOENA
-> -FREQ 100.000000
-> Starting UDP_ClientServer...
-> UDP_ClientServer::init() entry ...
-> UDP Server on wlan0 IP: 192.168.1.10 PORT: 9930
-> UDP Server fd: 3
-> Bind to IP address: 0.0.0.0
-> UDP_ClientServer::init() creating thread ::server_listener(void*) ...
-> UDP_ClientServer::init() exit ...
-> main - Opening server on IRQ 37
-> main - rt_intr_create - interrupt object created on IRQ 37
-> UDP_ClientServer::server_listener(void*) entry ...
-> rt_task_create created task MyIrqServer
-> disabling and reseting the I2C1 peripheral, writing I2C_CON = 0x0
-> disabling and reseting the I2C2 peripheral, writing I2C_CON = 0x0
-> rt_task_start started thread MyIrqServer
-> started real-time interrupt server thread for IRQ37
-> pausing ...
-> *** irq_server entry ***
-> Task name: MyIrqServer
-> initializing the pru subsystem driver
-> prussdrv_open() opened pru interrupt...
-> prussdrv_map_prumem completed...
-> initializing 16 x 32-bit words of p_pru_shared_memu ...
-> current value @ p_pru_shared_memu[0] : 0
-> current value @ p_pru_shared_memu[0] : 10000000
-> mapped device (Success)
-> *** mem mapped CM_PER registers...
-> enabling I2C1 peripheral clocking, writing CM_PER_I2C1_CLKCTRL = 0x02
-> CM_PER_I2C1_CLKCTRL: 00000002
Тема создана, как показано ниже. (Void *) этот указатель предоставляется как аргумент, передаваемый pthread_create в метод экземпляра класса :: server_listener.
printf("\t-> UDP_ClientServer::init() creating thread ::server_listener(void*) ...\n");
void*(*server_listener_fptr)(void*); // declare the function ptr
server_listener_fptr = reinterpret_cast<void*(*)(void*)>(&UDP_ClientServer::server_listener);
iret = pthread_create(&s_thread, NULL, server_listener_fptr, this);
Поток spawned :: server_listener никогда не завершается, как показано ниже.
void* UDP_ClientServer::server_listener(void*ptr)
{
printf("\t-> UDP_ClientServer::server_listener(void*) entry ...\n");
for(;;) /* Run forever */
{
Это, конечно, дает программисту уникальную возможность описывать сложные конечные автоматы в надежных параллельных и последовательных процессах, аналогично методам, используемым при написании RTL в VHDL или Verilog.
Ответ на вопрос просто, что для класса
class My_Class
{
public:
My_Class();
void func(void);
};
Для объявления экземпляра объекта класса
My_Class instance;
Вызов экземпляра объекта класса члену
instance.func(void);
По определению спецификация языка C ++, скомпилированная в
func(&instance);
Где пропущенная ссылка&Экземпляр ‘IS’ указатель ‘this’ члена.
Другие решения
Других решений пока нет …