fork or threads

Discussion in 'C++' started by =?ISO-8859-1?Q?Andreas_M=FCller?=, May 10, 2005.

  1. i need two loops that run forever. one of it receives data and stores it
    to a vector. the other one writes the elements of the vector to the
    disk. this means the vector is a receiver buffer. How can I realize
    this? by using threads or fork? Is it possible to access the vector in
    both loops with the current data?
    =?ISO-8859-1?Q?Andreas_M=FCller?=, May 10, 2005
    #1
    1. Advertising

  2. =?ISO-8859-1?Q?Andreas_M=FCller?=

    Lionel B Guest

    "Andreas Müller" <> wrote in message
    news:d5pof6$vu7$-tuebingen.de...
    > i need two loops that run forever. one of it receives data and stores it
    > to a vector. the other one writes the elements of the vector to the
    > disk. this means the vector is a receiver buffer. How can I realize
    > this? by using threads or fork? Is it possible to access the vector in
    > both loops with the current data?


    Way too little information... what do you mean by "receives data"? What data? "Receives" it how? Are the "receiving" and
    writing to be synchronous or asynchronous?

    In short, what are you trying to do (and what has it got to do with the C++ language)? Help us to help you ;-)

    --
    Lionel B
    Lionel B, May 10, 2005
    #2
    1. Advertising

  3. Lionel B wrote:
    > "Andreas Müller" <> wrote inmessage
    > news:d5pof6$vu7$-tuebingen.de...
    >
    >>i need two loops that run forever. one of it receives data and stores it
    >>to a vector. the other one writes the elements of the vector to the
    >>disk. this means the vector is a receiver buffer. How can I realize
    >>this? by using threads or fork? Is it possible to access the vector in
    >>both loops with the current data?

    >
    >
    > Way too little information... what do you mean by "receives data"? Whatdata? "Receives" it how? Are the "receiving" and
    > writing to be synchronous or asynchronous?
    >
    > In short, what are you trying to do (and what has it got to do with theC++ language)? Help us to help you ;-)
    >


    I'm using a sctp-library that receives video-frames from a sending
    server. Each frame has a timestamp to determine the time I have to write
    it to disk (this means to show it on the screen).
    In the receiving loop I want to store all the incoming data to a vector
    of structs or a map by the push_back function. this will run forever.
    I guess I need another thread to write the first element of the vector
    to the disk. This will occur when the timestamp of this element matches.
    Is it clear enough? I need access to the vector in both threads, in the
    first one to store all incoming frames to the vector, in the 2nd one to
    write the elements to the disk and to delete the written element. Is it
    possible to use a global vector and mutex to protect it?
    =?ISO-8859-1?Q?Andreas_M=FCller?=, May 10, 2005
    #3
  4. =?ISO-8859-1?Q?Andreas_M=FCller?=

    Kanenas Guest

    On Tue, 10 May 2005 10:15:39 +0200, Andreas Müller
    <> wrote:

    >Lionel B wrote:
    >> "Andreas Müller" <> wrote in message
    >> news:d5pof6$vu7$-tuebingen.de...
    >>
    >>>i need two loops that run forever. one of it receives data and stores it
    >>>to a vector. the other one writes the elements of the vector to the
    >>>disk. this means the vector is a receiver buffer. How can I realize
    >>>this? by using threads or fork? Is it possible to access the vector in
    >>>both loops with the current data?

    [...]
    >
    >I'm using a sctp-library that receives video-frames from a sending
    >server. Each frame has a timestamp to determine the time I have to write
    >it to disk (this means to show it on the screen).
    >In the receiving loop I want to store all the incoming data to a vector
    >of structs or a map by the push_back function. this will run forever.
    >I guess I need another thread to write the first element of the vector
    >to the disk. This will occur when the timestamp of this element matches.
    >Is it clear enough? I need access to the vector in both threads, in the
    >first one to store all incoming frames to the vector, in the 2nd one to
    >write the elements to the disk and to delete the written element. Is it
    >possible to use a global vector and mutex to protect it?


    C++ contains no concept of concurrency. As the question is OT, post
    on comp.programming.threads if you have further questions about
    threading.

    My personal recommendation is to use threads for the reader/writer and
    a queue (wrapped around a list or dequeue) rather than a vector to
    store the frames.

    Why threads? Ease of design, mostly, but use of a shared vector and
    processes may affect stability (in extreme cases). Usually, processes
    have separate address spaces and so different processes will not share
    global/local/heap variables. "Usually" doesn't mean it's impossible,
    it just means your program would have to use shared memory (e.g.
    shmget / shmat, CreateFileMapping / OpenFileMapping / MapViewOfFile)
    and placement new. You'll need to create an allocater which uses
    shared memory, use that allocator to create a vector which also uses
    said allocator. That way, whatever dynamically allocated objects the
    vector needs will be allocated within shared memory.

    One problem with this approach is the extra work on your part; a
    threaded approach (with mutexes &c) will probably be more efficient to
    design and create than using processes. Another problem is that
    shared memory may have a time/space tradeoff, depending on how it's
    implemented. A consequence of this along with the fact that shared
    memory often isn't resizable is that you have to worry about running
    out of space. This will become particularly important when the vector
    needs to grow, which will require a contiguous region of the shared
    memory large enough to contain the new data. This implies shared
    memory should be roughly at least 3 times what you expect the maximum
    size of the vector will be. Even then, there may be times when the
    reader reigns supreme and you run out of memory when the vector grows.
    This is how the process/shared vector approach affects stability.

    From your description, your reader/writer mostly operate at the ends
    of the vector. A list or deque is much more efficient for operations
    at the ends. Furthermore, for the shared memory approach, a list
    doesn't need the arena to be three times as big as its expected
    maximum size.

    To reiterate: the "best" approach is threaded with a frame queue
    (wrapping around list or dequeue) protected by a mutex or semaphore.
    Just make sure you have a mechanism to prevent either the reader or
    the writer from dominating access to the queue.

    Kanenas
    Kanenas, May 18, 2005
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ajay Bakhshi
    Replies:
    0
    Views:
    398
    Ajay Bakhshi
    May 3, 2004
  2. Eric Snow

    os.fork and pty.fork

    Eric Snow, Jan 8, 2009, in forum: Python
    Replies:
    0
    Views:
    563
    Eric Snow
    Jan 8, 2009
  3. grocery_stocker
    Replies:
    12
    Views:
    403
  4. Tomasz Pajor

    fork, threads and proper closing

    Tomasz Pajor, Jun 28, 2009, in forum: Python
    Replies:
    5
    Views:
    246
    Lawrence D'Oliveiro
    Jun 30, 2009
  5. James Gray

    Threads After Fork

    James Gray, Jan 20, 2009, in forum: Ruby
    Replies:
    3
    Views:
    151
    Bertram Scharpf
    Jan 21, 2009
Loading...

Share This Page