Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>This type of implementation only works if you can afford to miss an event. I just tested it and ran into many deadlocks. The main reason for this is that the condition variables only wake up a thread that is already waiting. Signals issued before are lost.</p> <p>No counter is associated with a condition that allows a waiting thread to simply continue if the condition has already been signalled. Windows Events support this type of use.</p> <p>I can think of no better solution than taking a semaphore (the POSIX version is very easy to use) that is initialized to zero, using <code>sem_post()</code> for <code>set()</code> and <code>sem_wait()</code> for <code>wait()</code>. You can surely think of a way to have the semaphore count to a maximum of 1 using <code>sem_getvalue()</code></p> <p>That said I have no idea whether the POSIX semaphores are just a neat interface to the Linux semaphores or what the performance penalties are.</p>
    singulars
    1. This table or related slice is empty.
    1. POpthread condition variables vs win32 events (linux vs windows-ce)
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USTaryn
    1. USeverclear
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. COthat is why a condition variable is always associated to... a condition. you use a mutex to ensure coherent access to that condition, and you check for it in a while loop. (to account for spurious wake ups, and concurrently mutex acquiring threads that may have changed the condition after the notify.)
      singulars
      1. PO
      1. USv.oddou
    2. COThe problem I'm going for is an event that occurs once. Think of a thread that dispatches other threads. For example you want to continue execution of the dispacher only if the dispached thread has actually run for some time. For this I use two semaphores: The dispatcher creates the thread and posts a 'dispatch' semaphore. The dispatched thread waits for it. After setting the dispatch semaphore the dispatcher waits for a worker semaphore to be posted by the worker. This mechanism fails using the events above because in most cases the worker will miss the dispatcher's signal and block forever.
      singulars
      1. PO
      1. USeverclear
    3. COWell yes of course. that is why condition variables do not focus on the event, but on the condition. your condition is a variable, for example a bool that flags 'go for it !' that your worker will read. If it is false, it waits on the condition_variable until a signal, it wakes up, checks the 'go for it flag'. If the flag is true it means the signal was sent before the worker arrived at that point so it doesn't even wait. the mutex is here to access this flag with the correct memory barriers.
      singulars
      1. PO
      1. USv.oddou
 

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