• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Multiprocessor problem?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Multiprocessor problem?


  • Subject: Re: Multiprocessor problem?
  • From: Mark Hunt <email@hidden>
  • Date: Tue, 18 Mar 2003 09:40:38 +0000

Justin

>> Hi
>>
>> I have an App that crashes occasionally on dual processor machines.
>> The computer appears to become bus-locked, but it's hard to be sure.
>> Only a reset/power cycle will bring it back.
>>
>> OS is 10.2.4. Any dual-cpu Mac will do!
>>
>> Some minor changes to the network code seem to changed the probability
>> of this bug.
>>
>> My networking code uses a blocking BSD socket, which places part of
>> the packet data into a circular array of buffers when it unblocks
>> (data arrives), and loops.
>>
>> Is it possible for this code to execute concurrently (on both
>> processors at the same time) for different packets? This would
>> definitely explain my problem!
>
> It theoretically not possible for this to happen [but there's a
> difference between theory and practice...]. The BSD part of the kernel
> uses one of two funnels to avoid running into this kind of race
> condition. One of the funnels is specifically for code that touches
> the networking infrastructure, and the other is for everything else.

It does seem strange, as (re-reading my original mail) it would imply
that I'm getting data before I've called recvfrom!

> Is this 'app' purely user-mode, or does it have some kernel code
> associated with it (that you have developed)?

I'm totally in user-land!

The code that calls "recvfrom" is in a single MPThread (based on the
BSDLLCtest sample code). The buffer array is allocated in my global
variable space.

My original code did this:

bcopy(&hdr->data[id].data, msg_queue[msg_put], count);
msg_queue[msg_put].size = count; // save packet size
msg_put += 1;
if(msg_put >= kBufferCount) msg_put = 0; // circular buffer

I spotted that there was a brief period when msg_put could point
outside the array, so I modified it so that it uses a local variable
(idx), instead of the "live" one, and updated msg_put by a single store:

idx = msg_put;
bcopy(&hdr->data[id].data, msg_queue[idx], count);
msg_queue[idx].size = count; // save packet size
idx += 1;
if(idx >= kBufferCount) idx = 0; // circular buffer
msg_put = idx;

The bug "seems" to have gone away, but I don't understand why this
would crash the Mac so comprehensively!
I'd be a lot happier if I knew.

The client thread that takes messages from the array uses a separate
msg_get index - the only access to msg_put in this thread is to compare
msg_put and msg_get for equality. The bug should only have caused a
re-read of the array contents!

BTW, does my buffer array need to be virtual memory safe? This MPThread
is just "ordinary" code outside the recvfrom, right?

Thanks

Mark
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • Re: Multiprocessor problem?
      • From: Justin Walker <email@hidden>
  • Prev by Date: Internal modem API's query
  • Next by Date: Re: Multi-link PPP
  • Previous by thread: Re: Multiprocessor problem?
  • Next by thread: Re: Multiprocessor problem?
  • Index(es):
    • Date
    • Thread