Had an idea for thread queing, looking for thoughts

[awsdert]

This is currently all I have (because I don't wanna accidentally crash my computer if possible):

typedef struct zque {
	int id;
	int ret;
	_Bool active;
	uint thread;
	uint glance, change;
} zque_t;
#define zque_null ((zque_t){-1,0})

int zque_get_change_perm( zque_t *zque, uint sec )
{
	uint change = ++(zque->change);
	while ( zque->thread != change )
	{
		sleep(sec);
		if ( !(zque->active) ) return -1;
	}
	return 0;
}

Aside from naming convention (I'll probably change that 'z' to 'mcc_' later), what are your thoughts on this? Any potential problems you can see?

Edit: Just noticed a left over from when I initially planned to work with an fd, removed now

[awsdert]

Someone will probably ask about how I plan to remove permission since decrementing can confuse the thread managing the que, it's a simple as this:

void zque_rem_change_perm( zque_t *zque )
{
	zque->thread = 0;
}

That's it, the managing thread will do the decrementing itself and only when glance/change is not 0, threads asking for permission should only increment while the managing thread should only decrement after passing the current value to zque->thread

[laserlight]

Are you basically implementing a semaphore?

[awsdert]

Are you basically implementing a semaphore?

Dunno what that is, gimme a moment to look it up

[awsdert]

Dunno what that is, gimme a moment to look it up

Judging from what I saw on wikipedia I'd say yes but without any knowledge of the resources, this is merely to prevent changes occurring to the accompanying data while another is trying to change or glance at it, simple example of intent:

typdef struct zthread {
  uint count;
 zque_t zque;
} zthread_t;
...
ret = zque_get_change_perm( &(zthread->zque), 1 );
if ( ret == -1 ) return;
zthread->count++;
zque_rem_change_perm( &(zthread->zque) );
// here on only reads of non-allocated data should occur

Also after thinking about it while waiting for a reply I decided to merge the glance & change variables into one for the sake of avoiding more race based scenarios I thought of that would occur otherwise so the code now looks like this:

typedef struct zque {
	int id;
	int ret;
	_Bool active;
	uint pos;
	uint que;
} zque_t;
#define zque_null ((zque_t){-1,0})

int zque_get_rwperm( zque_t *zque, uint sec )
{
	uint pos = ++(zque->que);
	while ( zque->pos != pos )
	{
		sleep(sec);
		if ( !(zque->active) ) return -1;
	}
	return 0;
}

void zque_rem_rwperm( zque_t *zque )
{
	zque->pos = 0;
}

[Salem]

Why aren't you using actual pthread primitives?

[awsdert]

Why aren't you using actual pthread primitives?

Remember how I'm making my own compiler? I wanted something to fallback on when pthreads is unavailable and the first step to that is a que mechanism that can be used along side pthreads (which I'm doing for the sake of testing)

[Salem]

Except things like threads, concurrency and synchronisation are more like platform issues rather than compiler issues.

> uint pos = ++(zque->que);
If you let two threads pointing at the same zque do this, then you're in for surprises at some point.
Look up the __atomic (or __sync in older versions) primitives in GCC.

Are you writing your own OS to go along with the compiler?

[awsdert]

Except things like threads, concurrency and synchronisation are more like platform issues rather than compiler issues.

> uint pos = ++(zque->que);
If you let two threads pointing at the same zque do this, then you're in for surprises at some point.
Look up the __atomic (or __sync in older versions) primitives in GCC.

Are you writing your own OS to go along with the compiler?

I'm certainly dabling in the idea of a bootable mitsy compiler, I think it would be most useful for new systems where jnstalling a whole OS just to get optimal binaries of a compiler would be a bit much, in that scenario mitsy would first have to rely on its fallbacks and then try optimizing based on its live experience of the system

[awsdert]

Except things like threads, concurrency and synchronisation are more like platform issues rather than compiler issues.

> uint pos = ++(zque->que);
If you let two threads pointing at the same zque do this, then you're in for surprises at some point.
Look up the __atomic (or __sync in older versions) primitives in GCC.

Are you writing your own OS to go along with the compiler?

K, I finally got bored of playing DQB2 and am in the mood to program again, I tried looking up that __atomic but couldn't understand how to use it to achieve similar behavior that is thread safe, mind giving me an example? (googling gave me non-usable results or I just used the wrong "terms" which was just the word __atomic)