Beautiful.
I was playing with the code, and didn't make the jump that you only need to
SIGNAL the second transition.
You're right about private data. In fact, I intend to put the
mutex/lock/condition code in owlib and so simplify the owcapi code. Again, to
make it easier to see the code and use it as a prototype for other programs.
This gets to a larger question: what should be internal to owlib, and what
should be in ow.h that is used by other programs. In the past, the only
direct clients of owlib were the included programs owfs., owhttpd,
owserver, ... They reached into owlib at varying levels, and the effort of
data hiding wasn't worth the complication. I guess owcapi will be the
buffering layer.
Paul
On Monday 17 October 2005 10:24 am, Geo Carncross wrote:
> A mutual exclusion device is necessary.
>
> OW_get, OW_put, and OW_finish all lock the common mutex.
>
> If OW_get and OW_put /really can/ be used simultaneously, then a
> condition is required:
>
>
> in OW_get and OW_put:
>
> LOCK(mutex);
> level++;
> UNLOCK(mutex);
> { real code }
> LOCK(mutex);
> level--;
> SIGNAL(cond);
> UNLOCK(mutex);
>
>
> and in OW_finish:
>
> LOCK(mutex);
> while (level > 0) COND(cond,mutex);
> { destroy interface safely now }
> UNLOCK(mutex);
>
>
> in pthreads this is:
>
> pthread_cond_t cond;
> pthread_mutex_t mutex;
>
> #define COND(q,p) pthread_cond_wait(&q,&p)
> #define SIGNAL(q) pthread_cond_signal(&q)
> #define LOCK(q) pthread_mutex_lock(&q)
> #define UNLOCK(q) pthread_mutex_unlock(&q)
>
>
> NOTE: this is NOT the same mutex as you're using for acessing indev
> (capi_mutex) - but a different one JUST for this cond variable.
>
>
> BY THE WAY, shouldn't these things be static? Is there really a reason
> user programs should have access to it?
>
> On Sun, 2005-10-16 at 22:57 -0400, Paul Alfille wrote:
> > Added the same protection for the SWIG prototype (owperl, owpython,
> > owphp).
> >
> > It occurs to me that it is possible that a "OW_finish" could be called
> > while an OW_get or OW_put is in progress -- could be messy since the
> > adapters would be disappearing while being used. I'll have to get out the
> > old textbook to figure the proper flag for this one -- a semaphore?
> >
> > Paul
> >
> > On Sunday 16 October 2005 01:33 am, Paul Alfille wrote:
> > > Ok uploaded some OWCAPI changes.
> > >
> > > 1. I've put in your char** mode. I'm really starting to warm up to it.
> > >
> > > 2. Protection against multiple "init"s, no "init"s, simultaneous
> > > "init"s...
> > >
> > > Paul
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by:
> > Power Architecture Resource Center: Free content, downloads, discussions,
> > and more. http://solutions.newsforge.com/ibmarch.tmpl
> > _______________________________________________
> > Owfs-developers mailing list
> > Owfs-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/owfs-developers
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
