ล็อค io watcher และนาฬิกาจับเวลาใน libev

ใน libev ฉันได้เริ่มต้น io watcher เพื่อจับเหตุการณ์และเหตุการณ์นี้ทำให้เก็บค่าบางอย่างไว้ในแคชบางตัว ฉันมีตัวจับเวลาอีกอันที่ทำงานทุกๆ 10 วินาที อ่านค่าแคช ในกรณีเช่นนี้ ฉันคิดว่ามีสภาพการแข่งขัน ฉันต้องใช้การล็อคใน libev watcher สองตัวที่แตกต่างกันหรือ libev จัดการมัน

eg:

 TCP_CACHE_TIMEOUT = g_hash_table_new_full(g_str_hash, g_int_equal, key_destroy_cb, value_destroy_timeoutcb);
    zlog_info(_c,"TCP Server started at _port: %d",_port);
    int fd =setup_tcp_socket(_port);
    if(fd<0)
    {
        return NULL;
    }

    struct ev_loop *loop = EV_DEFAULT;

    struct _sock_ev_serv server;
    server.fd = fd;
    ev_io_init(&server.io, event_server, server.fd, EV_READ);
    ev_io_start(EV_A_ &server.io);

    ev_timer_init (&timeout_watcher, timeout_idle_fd, 0, 10.);
    ev_timer_again (loop,&timeout_watcher);

    ev_loop(loop, 0);

ที่นี่ฉันมีการวนซ้ำและเริ่มต้น io watcher เพื่อยอมรับเหตุการณ์เซิร์ฟเวอร์ และตัวจับเวลาเพื่อดูในแคชทุกๆ 10 วินาที ในกรณีเช่นนี้ ฉันจำเป็นต้องจัดการสภาพการแข่งขันด้วยตัวเองหรือผู้เฝ้าดู io สองคนและเวลารันไทม์เมอร์ได้รับการจัดการโดย libev หรือไม่


c race-condition libev
person user5335302    schedule 15.01.2016    source แหล่งที่มา

คำตอบ (1)


arrow_upward
1
arrow_downward

คำตอบสั้นๆ: ไม่มีสภาพการแข่งขัน คุณไม่จำเป็นต้องล็อค

คำตอบที่ยาวกว่า:
เหตุผลที่ไม่มีสภาพการแข่งขันเป็นเพราะ libev อยู่ในลูปที่กำลังตรวจสอบ io watcher จากนั้นจึงจับเวลา จากนั้น io จากนั้นจึงจับเวลา.....
แล้วแต่อันไหน จะถูกกระตุ้นก่อน จะถูกเรียกใช้ก่อน ไม่มีการทับซ้อนกันระหว่างการโทรกลับทั้งสอง

อย่างไรก็ตาม หากคุณใช้เธรดเหตุการณ์แบบวนซ้ำ (เป็นไปได้ แต่ไม่น่าจะตัดสินโดยโค้ดของคุณ) และคุณกำลังอ่านจากไฟล์เดียวกันในสองเธรดที่ต่างกัน แสดงว่าอาจมีสภาวะการแข่งขันและคุณจะต้องมีการล็อค

ตัวอย่าง:
หากคุณได้รับข้อมูลใน io watcher หลังจากผ่านไป 0.9 วินาที และการโทรกลับสำหรับ watcher นั้นใช้เวลา 0.2 วินาทีในการทำงาน ตัวจับเวลาของคุณจะถูกเรียกใช้หลังจากที่การโทรกลับ io เสร็จสิ้นแล้ว (ที่ ~10.1 วินาที)

person Community    schedule 11.02.2016