I took a quick look.
The paper gives an algorithm for implementing a queue, and your code
implements
a stack. The stack implementation contains a few race conditions. For
example, say that thread A pops
and thread B pops as well; after thread A frees a node, thread B could try
to free it again,
At first glance, making the functions polymorphic (as opposed to templates)
could be a potential reason for segmentation faults (see
https://github.com/githwxi/ATS-Postiats/issues/216). Though mixing dependent
types and templates together has also been known to cause issues (see
One very serious danger with using alloca is that alloca interferes with
tail-call
optimization. After debugging code using alloca a couple times, I would be
really
hard pressed to every use alloca again.
On Saturday, February 23, 2019 at 6:24:24 AM UTC-5, Artyom Shalkhakov wrote:
>
> Hi
I don't think it's due to polymorphic functions, because the problem
goes away when I switch to using only one thread.
Cheers,
Vanessa
On 3/1/19 8:43 PM, Richard wrote:
> At first glance, making the functions polymorphic (as opposed to templates)
> could be a potential reason for segmentation
If we ignore malloc/free, then lock-free stack implementation
should look more or less like the following code:
fun
pop(theStack) = let
var xs0 = theStack
in
case+ xs0 of
| nil() => None_vt()
| cons(x0, xs1) =>
if atomic_compare_exchange(theStack, xs0, xs1)
then Some_vt(x0)
