is object_alloc thread-safe?

Hi folks.
Thank you for your explainations, first.

I’ll try to make some things clearer.

Tim, I am aware that object_alloc does more than merely allocating memory – I just (wrongly) assumed that memory allocation was the only thread-risky part of the operation.

Anyway, the class I’m frantically instantiating is a nobox one.

The crash log doesn’t really help. The point is that my data are corrupted in a (very systematic) way that eventually causes a crash. What I remarked is that inside my data structure I unmistakably recognize some data belonging to a message box elsewhere in the patch – this is why I was wondering if there was a memory allocation problem, kind of the same block of memory allocated twice because of a thread-safety problem.

This thing of the message box is a quite intriguing one. The metro and qmetro are actually connected to a message box (containing 1 2 5), which in turns is connected to my object [reg]. Besides the toggles and number boxes for the metro and qmetro, there’s nothing more in the patch. When [reg] receives a list, this is a simplified version of what happens:

void reg_list(t_reg *x, t_symbol *sym, long ac, t_atom *av) {
	t_llll *new_llll = object_new_typed(_sym_nobox, _sym_llll, ac, av); // object_alloc is in llll's "new" method
	if (!new_llll)
		return;
	systhread_mutex_lock(x->lock);
	object_free(x->cache);
	x->cache = new_llll;
	systhread_mutex_unlock(x->lock);
	if (inlet == 0)
		reg_bang(x);
}

void reg_bang(t_reg *x) {
	t_atom parsed_wrapped, *parsed_atom;
	t_atomarray parsed_aa;
	systhread_mutex_lock(x->lock);
	object_method_typed(x->cache, gensym("clone", 0, NULL, wrapped);
	// clone is a GIMMEBACK method
	// it instantiates a new llll and clones "this" into it
	// but x->cache gets corrupted and clone crashes
	systhread_mutex_unlock(x->lock);
	atomarray_getatoms(parsed_aa = (t_atomarray *) atom_getobj(&parsed_wrapped), &out_ac, &parsed_atom);
	outlet_anything(x->outlet, _sym_foo, 1, parsed_atom);
	object_free(atom_getobj(parsed_atom));
	object_free(parsed_aa);
}

(As you can see, at the moment a new object is cached the previous one is freed; and the cloned object that is output is immediately destroyed thereafter.)

Now, deep inside my llll structure (not at the very beginning, though) I have two longs, one after another, that at the moment of the crash contain 2 and 5. This is not the immediate cause of the crash, but a clear symptom that something is wrong. If I change the contents of the message box, the two longs change accordingly. Now, this would suggest that someone stores the 2 and 5 inside a long[] or something like that – not in an atom[], because in this case they would not be aligned to my two longs in the object structure, right? Since in my object the incoming message is only stored inside atoms, I’m guessing someone else has written inside my object structure. This is why I was wondering about object_alloc.

Finally, this thing of banging my object from a very fast metro and qmetro doesn’t belong to a real-world scenario – it’s just for testing. Though, I don’t like it not to work…

As soon as I get more detalis about the problem, I’ll let you know!

aa

ps @ Siska: afaik, critical regions are basically recursive mutexes. This means that you can enter them more than once from the same thread (and you have to unlock them more than once, correspondingly). Besides the fact that you might not want this, criticals are much more expensive than regular mutexes – so in general you should avoid them when you don’t need them.

Hi!
So, I have found the bug (it was a very trivial one, inside the free method)
Thank you for your help – it really pointed me into the right direction

Cheers
aa