Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>What you want is something similar to a <code>std::future</code> in c++ (<a href="http://en.cppreference.com/w/cpp/thread/future" rel="nofollow">doc</a>). A consumer requests a task to be performed by a producer using a specific function. That function creates a struct called <em>future</em> (or <em>promise</em>), holding a mutex, a condition variable associated with the task as well as a void pointer for the result, and returns it to the caller. It also put that struct, the task id, and the parameters (if any) in a work queue handled by the producer.</p> <pre><code>struct future_s { pthread_mutex_t m; pthread_cond_t c; int flag; void *result; }; // basic task outline struct task_s { struct future_s result; int taskid; }; // specific "mytask" task struct mytask_s { struct future_s result; int taskid; int p1; float p2; }; future_s *do_mytask(int p1, float p2){ // allocate task data struct mytask_s * t = alloc_task(sizeof(struct mytask_s)); t-&gt;p1 = p1; t-&gt;p2 = p2; t-&gt;taskid = MYTASK_ID; task_queue_add(t); return (struct future_s *)t; } </code></pre> <p>Then the producer pull the task out of the queue, process it, and once terminated, put the result in the future and trigger the variable. </p> <p>The consumer may wait for the future or do something else.</p> <p>For a cancellable futures, include a flag in the struct to indicate that the task is cancelled. The future is then either:</p> <ul> <li>delivered, the consumer is the owner and must deallocate it</li> <li>cancelled, the producer remains the owner and disposes of it.</li> </ul> <p>The producer must therefore check that the future has not been cancelled before triggering the condition variable. </p> <p>For a "shared" future, the flag turns into a number of subscribers. If the number is above zero, the order must be delivered. The consumer owning the result is left to be decided between all consumers (First come first served? Is the result passed along to all consumers?).</p> <p>Any access to the future struct must be mutexed (which works well with the condition variable). </p> <p>Regarding the queues, they may be implemented using a linked list or an array (for versions with limited capacity). Since the functions creating the <em>futures</em> may be called concurrently, they have to be protected with a lock, which is usually implemented with a mutex.</p>
    singulars
    1. This table or related slice is empty.
    1. POOne thread showing interest in another thread (consumer / producer)
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USdidierc
    1. USdidierc
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POOne thread showing interest in another thread (consumer / producer)
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COI really like this advice, abstracting it into futures seems like a clean way to do it and I could always swap out pthreads if I decide to go cross-platform to windows. However I'd like some clarification on one thing: how do you see the "work queue" being handled? Locked tight by a mutex for every queue (if I decide to have possibly more than one)?
      singulars
      1. PO
      1. USAktau
    2. COYes. I updated my answer to include that idea. It is possible to make lockless version of containers, but for the time being you should probably start with locked ones, and if needed implement a lockless solution and **ensure** that there is a performance gain (it's not necessarily the case).
      singulars
      1. PO
      1. USdidierc
    3. COThanks, I'm satisfied that at least the base of my idea was ok (but needed a tad bit more abstraction). I'm concerned about performance in the long run, but much more than that even I'm concerned about stability. It absolutely, can, not, fail. That's why I've grudgingly allowed threads in my app even though I'm not very experienced with them. I know enough to see the havoc they can cause when used without concern. But I need it for my epoll_loop...
      singulars
      1. PO
      1. USAktau
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload