[ILUG] Asynchronous thread ipc

Ronan Cunniffe rcunniff at stp.dias.ie
Tue May 25 17:53:36 IST 2004



On Tue, 25 May 2004, Bryan O'Donoghue wrote:

>
> case 1.
>
> [blob of logic thread:1 does some stuff has some information which is shared
> between (n) threads]
> |
> |
> Time
> |
> |
> [blob of logic_2 thread:2 needs to know about stuff in blob of logic 1]
>
> case 2.
>
> Sometimes blob of logic 1 can happen *after* blob of logic 2.
>
>
> For case 2 a simple pthread_cond_time/dwait should suffice.
> For case 1, the asynchronous nature of the synchronisation violates that logic,
> so that
>
> [blob of logic1 thread:1 pthread_cond_broadcast(something);]
> |
> |
> [blob of logic2 pthread_cond_wait(something) : blocks forever]
>
> Which is bad.
>
> Right now I'm having thread 1, wait for thread 2 to become ready, which also is
> bad.
>
> [blob 1 : can be here pthread_cond_wait(something);]
> |
> time
> |
> [blob of logic 2 (thread_read==false){ nanosleep(for a while); } else {
> pthread_cond_broadcast(something);]
> |
> |
> time
> |
> [or blob of logic 1 can be here pthread_cond_wait]
>

I'm not sure I understand: is the problem that thread 1 might update twice
and at least one of threads 2 to n might miss a transition?

If so, one answer is to use two conditionals.  As soon as thread 1
updates, it triggers cond1, and waits on cond2.  The reading threads then
queue up to read the data (mutexes as appropriate), each modifying a
counter, and triggering cond2 when all threads have updated themselves.

Of course, I could be answering the wrong problem.

Ronan



More information about the ILUG mailing list