composability through condition lists...

[Chris Thomasson]

You can use a list of function pointers and pointers to state:

#define CONDLIST_STATE_IDLE() 0x1
#define CONDLIST_STATE_BUSY() 0x2

typedef struct condlist_s condlist_t;
typedef struct precicate_s predicate_t;

struct predicate_s {
predicate_t *next;
int (*fp_assert) (void*, unsigned);
void *state;
};

struct condlist_s {
predicate_t *front;
unsigned state;
pthread_mutex_t mutex;
pthread_cond_t cond;
};

The the predicates get processed in FIFO... We clearly define that the
predicate will be protected by a common mutex... Or, you can combine this
with:

http://groups.google.com/group/comp.programming.threads/browse_frm/thread/e0c011baf08844c4

To get more flexibility...

Humm... If you completely bind you applications synchronization scheme to
condition lists, why wouldn't this buy you functional programming? This
would be more efficient than STM.

Humm...

Any thoughts?

[Chris Thomasson]

"Chris Thomasson" <cri...@comcast.net> wrote in message
news:5v6dnX4kuqZVY_rY...@comcast.com...

> You can use a list of function pointers and pointers to state:

[...]

> Any thoughts?

You can process the condition list is a number of different ways. For
instance, you can treat it like a TM... You assert, and processes under the
protection of the lock... So, if all predicate hold up, you atomically
process... If a predicate is not satisfied, you block on the condition
variable or eventcount, whatever... You can extend this:

struct predicate_s {
predicate_t *next;
int (*fp_assert) (void*, unsigned);

int (*fp_process) (void*, unsigned);
void *state;
};

For signals... Well, when your code satisfies a predicate, and you want
forward progress in the TM, your signal/broadcast to the condition variable
or eventcount...

Any thoughts?

[Chris Thomasson]

"Chris Thomasson" <cri...@comcast.net> wrote in message

news:S-6dnaWG3O0nnfXY...@comcast.com...

You can get composability when you start blending predicates with one
another. This can be programmed for sure...