Hi Joe,
On Wed, Sep 14, 2011 at 6:10 PM, Joe Groff wrote:
> The compiler wouldn't break acquire/release semantics when optimizing around
> pthread_mutex_* calls, would it?
It shouldn't. It doesn't even re-order loads and stores to alien data right now.
Slava
--
On Sep 14, 2011, at 3:17 PM, Slava Pestov wrote:
> If you run Factor in one thread and your C code in another, then you
> should be able to just use pthread mutexes. Use the Factor FFI to bind
> to the pthread API, and put a lock inside your struct. Take the lock
> when you modify it.
The compile
Hi,
On Wed, Sep 14, 2011 at 1:46 PM, Marmaduke Woodman wrote:
> A quick solution that might work is to have a member in the struct 'locked'
> that you set to true before the factor writes and set to false when it has
> finished. Then in c, write the equivalent of
>
> While (not struct.locked) {
A quick solution that might work is to have a member in the struct 'locked'
that you set to true before the factor writes and set to false when it has
finished. Then in c, write the equivalent of
While (not struct.locked) { }
Before you read from the struct.
Because your read/write pattern is s
On 11-09-14 04:20 PM, Marmaduke Woodman wrote:
>
> Hi
>
> I just joined this list, and being new to factor, I don't want to
> comment on factor specific details, but I want to point out that a
> general problem in this situation is coordinating reads and writes of
> a common data structure.
>
>
Hi
I just joined this list, and being new to factor, I don't want to comment on
factor specific details, but I want to point out that a general problem in
this situation is coordinating reads and writes of a common data structure.
Typically you'd want the data structure to have a consistent state
From the docs and John Benidiktsson's blog:
http://re-factor.blogspot.com
"fun with wav"
I have learn quite a bit about the FFI. However if someone could guide
me, I just want to make sure I have a sensible design pattern for it.
My application is control of scientific instruments. The I/O f
