Re: URGENT PATCH: pthreads lockup fix

[Ali Akcaagac <ali akcaagac stud fh-wilhelmshaven de>]

On 2001.08.19 23:42:40 +0200 M . Thielker wrote:
> Sorry to deflate your balloon some, but the definition of NULL _is_ (void
> *)0 in most implementations. You most likely just replaced one apple with
> another apple :)

no problem. i figured out that i was wrong.

> In any case, a pointer is, in assembly, just passed as a 32 bit value.
> WHatever it looks like in source, if thet value is 0, you have a null
> pointer.

start:
  lea label(pc),a0
  move.l (a0),d0
...
...
...
...
  rts

label:
  dc.l 0

this could look like this in mc680x0 assembly, if i understand you right.

> So, (void *)0, (char *)0, (struct foo *)0 are all just the same, they're
> translated into loading a 0 into a register or onto the stack. That, by
> definition, is a NULL pointer. NULL is defined as a (void *) just to make
> the compiler happy when giving NULL to a function expecting a typed pointer
> because C will accept a void * anywhere a typed pointer is legal, except in
> pointer arithmetic or dereferencing it.

yeah.. i see, well i really was to fast with my last mail to the mailinglist
but during my lifetime ive seen to many courious behaves where things that
are clean and likely are not that what it should be as result but in this
case it doesnt matter. you are absolutely right.

but hey, under assembly putting values on the stack is quite different you
usually move values to a different register e.g.

start:
  bsr.b loop
  rts

loop:
  rts

in this case the current address of the PC gets saved to the stackpointer
before the BSR could take place whenever it RTS'es from loop the value
gets moved out of the stack.

we could also write values straight to the stack either with pop or push
values but most common is this

start:
  movem.l d0-d7/a0-a6,-(sp)
...
...
...
...
  movem.l (sp)+,d0-d7/a0-a6
  rts

in any case my understanding in assembly language is often easier and
faster than hasseling with 'c' since i am a assembly writing kind of
person for my whole lifetime writting programs in 'c' is usually more
a pain to me, since it's quite different from the easy understanding
of clear assembly instructions.

> In my opinion, the lockup is more common on SMP machines because only SMP
> can achieve true concurrency. The lockup occurs on UP machines as well.
> Assume the following:
> 
> func a(...)
> {
> 	lock_mutt();
> 	gdk_threads_enter();
> 	.
> 	.
> 	.
> 	gdk_threads_leave();
> 	unlock_mutt();
> }
> 
> func b(...)
> {
> 	gdk_threads_enter();
> 	lock_mutt();
> 	.
> 	.
> 	.
> 	unlock_mutt();
> 	gdk_threads_leave();
> }

[snip]

> I really don't have the time to dig into this, I haven't had any lockups
> since I implemented "Quiet background check" and checked it, so I have found
> a workaround that keeps Balsa usable for me. But maybe, using the pointers
> given above, someone else more familiar with the code involved can find
> something...

wow, this was a piece of explaination. well i for my side am up reading
the pthreads reference manual and tweaking the balsa code now. maybe i take
more care this time before doing something strange i went already through
all pthread related things within src/* and as far from my understanding
they look quite reasonable well there are only 2 things ive found that i
would never do myself in that way but ok. i leave it as it is now. since
it doesnt behave different when i changed it and because of its not the
issue i am searchinf for right now.

i really want to finally find out and KNOW if this is my SYSTEM's fault
or probably a problem in one of balsa related components.

oki since i belive someone else's reading this too then here what i use

i use POP3 to retrive my emails so it must be the pop3 related code that
is damaged. since sending mail with balsa and esmtp works perfectly using
pthreads, also accessing the mailboxnodes works perfectly. after scanning
the src/* directory for pthread related things, i've came to the conclusion
that everything may be OK (from my understanding that far).

-- 
Name....: Ali Akcaagac
Status..: Student Of Computer & Economic Science
E-Mail..: mailto:ali.akcaagac@stud.fh-wilhelmshaven.de
WWW.....: http://www.fh-wilhelmshaven.de/~akcaagaa