libmicrohttpd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libmicrohttpd] libmicrohttpd, serialized access


From: Martin Velek
Subject: Re: [libmicrohttpd] libmicrohttpd, serialized access
Date: Sun, 29 Jun 2014 23:12:55 +0200

Hi,

I am using FreeRTOS running on CortexM3. Every mutex takes valuable
resources (SRAM and a record in the handle table). The NOP should be
No operation, e.g. the create function returns valid value but not
takes any resources, lock/unlock/delete does nothing. I have to
replace the pthread_mutex_* anyway because the FreeRTOS does not
support POSIX threads.

I think the logic should not be broken but I do not know if there is
code starting some thread requiring to lock the mutex even with
MHD_USE_SELECT_INTERNALLY. I did not notice and find such behaviour so
far. To convince myself I had to ask :).

Regards
Martin

On Fri, Jun 27, 2014 at 11:44 AM, Christian Grothoff
<address@hidden> wrote:
> Hi!
>
> If you're on Linux, this is almost the case, as with a single thread
> you obviously cannot have lock contention, and you're using a Futex
> (http://en.wikipedia.org/wiki/Futex) -- so the cost is very close to
> that of a NOP (no system call).  In fact, I would be surprised if
> replacing the logic with the equivalent of "if (! (daemon->options &
> MHD_USE_SELECT_INTERNALLY)) lock()" would give you any speed-up (it'd
> still technically be a branch and not a real NOP).
>
> Anyway, if you have a different reason for asking (other than
> performance concerns) or have real data showing that there is a
> difference, please explain more and I'll be happy to listen.
>
> Happy hacking!
>
> Christian
>
> On 06/27/2014 11:18 AM, Martin Velek wrote:
>> Hello,
>>
>> I am using libmicrohttpd with the MHD_USE_SELECT_INTERNALLY flag only
>> (one thread). Every request is processed in the libmicrohttpd thread
>> and neither MHD_Connection * nor MHD_Response * are processed outside
>> the thread.
>>
>> Is it possible to make all pthread_mutex_* calls as no-ops?
>>
>> Martin
>>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]