On 31/01/2019 13:41, Andres Monteverde wrote:
Hi Sebastian, Thank you for your prompt response.
> I don't think this is correct. If you call _MPCI_Send_request_packet(),
> then the ownership of this packet is transferred to the implementation
> of this function. With the shared memory driver, the packet is freed by
> the receiver, see Shm_Free_envelope()."
If you think that it's not correct, we can move the returning of the
packet inside _MPCI_Send_request_packet() but the reason why we return
the packet outside _MPCI_Send_request_packet() is because we were
focalized in queue behaviour and a change inside
_MPCI_Send_request_packet() is a broad solution with an unknown effect
for the test.
Regarding "the packet is freed by the receiver, see
Shm_Free_envelope()", by looking at the code and running the code step
by step with jtag, the core0 (the owner of the queue) does not return
the packet in any case.
The core0 MPCI handler for the receive request is:
_Message_queue_MP_Process_packet()
case MESSAGE_QUEUE_MP_RECEIVE_REQUEST:
the_packet->Prefix.return_code = rtems_message_queue_receive(
the_packet->Prefix.id,
the_packet->Buffer.buffer,
&the_packet->size,
the_packet->option_set,
the_packet->Prefix.timeout
);
if ( the_packet->Prefix.return_code != RTEMS_PROXY_BLOCKING )
_Message_queue_MP_Send_response_packet(
MESSAGE_QUEUE_MP_RECEIVE_RESPONSE,
the_packet->Prefix.id,
_Thread_Executing
);
break;
The core1 MPCI handler for the receive response is:
_Message_queue_MP_Process_packet()
case MESSAGE_QUEUE_MP_RECEIVE_RESPONSE:
the_thread = _MPCI_Process_response( the_packet_prefix );
if (the_packet->Prefix.return_code == RTEMS_SUCCESSFUL) {
*(size_t *) the_thread->Wait.return_argument =
the_packet->size;
_CORE_message_queue_Copy_buffer(
the_packet->Buffer.buffer,
the_thread->Wait.return_argument_second.mutable_object,
the_packet->size
);
}
_MPCI_Return_packet( the_packet_prefix );
break;
As far as i understand is the core 1 who frees the packet.
Yes, this is also my understanding.
And in case of a timeout waiting at the queue, there is no response at
all from core 0 so there's no return for the allocated packet nor the
proxy.
These are probably two independent problems.
Core 1 must still receive this packet at some time and free it.
The lost proxy in case of a timeout is another issue.
I don't have time to look into the details at the moment.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : [email protected]
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
users mailing list
[email protected]
http://lists.rtems.org/mailman/listinfo/users
