Thread zombie and so ....

[Newbie]

I move the last question i asked about thread here.

[Newbie]

My question was :

SH4 on DC is a 200 MHZ CPU so the CPU time slice is very little.

To manage getting % of CPU time slice, we need a very accurate timer which could operate in nano (10E-9) seconds perhaps, because MHZ frequency means 10E-6 seconds period ... I am not sure.

Besides, the fact that the decoder runs on a separate thread make the thing difficult.

I tried to use the classic "timer_us_gettime64()" function by time subtraction concept.

I run the code without calling the decoder and get the execution time of the main routine then i make the same test calling the decode routine.

The result is not accurate but it seems that it takes 0 ms, probably a fraction of a ms that is not an integer ....

I am working on a object oriented version of your code to use it in my projects so i have make some modifications.

By the way, i have a thread question

I am not sure that all threads created by "thd_create" are disposed.
I could track them as they become zombie threads as their state is STATE_ZOMBIE (in thread.h).
But after ... the pointer returned by "thd_create" is not accurate to verify the dispose fact because it seems to be never null ....

Thanks for help.

The BlueCrab response was :

The pointers never get changed unless you change them. The thread code doesn't know where all your pointers are and thus can't overwrite them. Also, if you're using a relatively new version of KOS, you're going to need to make sure to either thd_join or thd_detach all your threads, otherwise they will sit around wasting memory forever (which is obviously bad).

[Newbie]

So when creating a thread, the returned pointer must be nulled manually after the thread will in the zombie state ?
Could thd_destroy be called on such zombie thread to dispose resources ?
I use a old KOS version and found the source code below :

Code: Select all

int thd_destroy(kthread_t *thd) {
	int oldirq = 0;

	/* Make sure there are no ints */
	oldirq = irq_disable();

	/* If any threads were waiting on this one, then go ahead
	   and unblock them. */
	genwait_wake_all(thd);

	/* De-schedule the thread if it's scheduled and free the
	   thread structure */
	thd_remove_from_runnable(thd);
	LIST_REMOVE(thd, t_list);

	/* Free its stack */
	free(thd->stack);

	/* Free the thread */
	free(thd);

	/* Put ints back the way they were */
	irq_restore(oldirq);

	return 0;
}

There are some free command disposing the thread pointer

[BlueCrab]

You don't have to NULL pointers that you're no longer using in C and free() will certainly not do it.

The only reason to NULL pointers out when you're not using them is for your own convenience and to make it easier for you to debug. It serves no purpose other than that in a non-garbage collected language like C.

thd_destroy() is not meant to be called by your own code, as the documentation for it says. It is meant only to be called by the reaper thread, thd_join() and thd_detach(). I probably should make it static so you can't actually call it... The only safe ways to clean up a thread are by those two functions: thd_join() and thd_detach() (or by creating the thread detached to start with, at which point the reaper thread will clean it up). Which you should use depends on whether you care about the return value of the thread.

If you're using an old version of KOS that doesn't have thd_join() or thd_detach(), then your threads get destroyed at some point after they end automatically -- they are always created detached. There were a few bugs along the line with things not getting deallocated properly in the thread's context, so I do recommend updating if at all possible. Otherwise, to avoid those bugs, you're going to have to backport code to fix it (or risk leaking memory), which would be a pain.

[Newbie]

Otherwise, to avoid those bugs, you're going to have to backport code to fix it (or risk leaking memory), which would be a pain.

Could you be more explicit please ?

[BlueCrab]

There were a whole bunch of bugs in the threading code that I fixed between 2010 and the present. I don't remember everything off the top of my head, but I'm sure you could find them by looking at the history on the Git repository. Also, I made a few things work more like they do on normal operating systems, such as making it so threads can return values and such.

[Newbie]

Ok !

SO is it this repository ?

https://github.com/losinggeneration/kos/tree/master/doc

[BlueCrab]

No, that is not the official KOS repo. That is a git repository that is a mirror of a really old SVN revision of KOS (which hasn't been touched in 5 years). Look here for information about the KOS git repo (or here if you just want to browse the code online).

I also maintain a mirror of the KOS repo on my server that gets updated any time I commit code, just in case sourceforge is ever down for an extended period of time.

[Newbie]

Well i read the difference of code between "my" KOS and "yours" and it's definitely impossible to update.
I need to recompile the update source on my old cygwin DCDEVR4 ...

[Newbie]

But i don't think it's an easy thing ...

[Newbie]

I have found your static reaper

static void *thd_reaper(void *param) {
kthread_t *thd;

(void)param;

for(;;) {
/* Wait til we have something to reap */
sem_wait(&thd_reap_sem);

/* Find the first zombie thread and reap it (only do one at a time so
that the semaphore stays current) */
LIST_FOREACH(thd, &thd_list, t_list) {
if(thd->state == STATE_ZOMBIE) {
thd_destroy(thd);
break;
}
}
}

/* Never reached */
abort();

[BlueCrab]

Unfortunately, the dev iso is pretty badly out of date. You'll basically have to recompile the entire toolchain to get it to work with a current version of the KOS source code. That said, there's a script that's included with KOS to do most of the hard work for you.

[Newbie]

I have read somewhere that recompiling all tool chain could take a lot of time ...
I will try and talk about that in an another thread.

Thanks for your help.

[BlueCrab]

Yes, it can take a lot of time -- especially on Cygwin.

On a native Linux or Mac machine, it'd probably take less than 2 hours. On Cygwin however it can take pretty much all day sometimes.

[Newbie]

Ok i have NOW a fresh toolchain (GCC 4.7.X) and KOS 2.x .

So what i must add to my code to ensure threads will be correctly disposed ?
Have you please a "generic" source sample to show me ?

Thanks.

[patbier]

Hello, KOS has already examples !
Have a look in : kallistios\examples\dreamcast\basic\threading
It really helps

[BlueCrab]

There's actually a bit of a mischaracterization of how things work in KOS in that example. There's a comment that implies that you have to enable IRQs manually, which is certainly not the case. IRQs (and thus threading) are enabled by the normal startup sequence. This hasn't been the case for a long time, and thus the comment really needs to be changed.

I've just fixed the comment (and moved a few things around in the code) in the Git repository, so you might want to take a look at the current version if you're looking for an example.