On Thu, Oct 25, 2012 at 10:31 AM, Gustaf Neumann <neum...@wu.ac.at> wrote:
> I don't think, that a major problem comes from the "racy"
> notification of queuing  events to the connection threads.
> This has advantages (make os responsible, which does this
> very efficiently, less mutex requirements) and disadvantages
> (little control).


I think the current code works something like this:

- driver thread acquires lock, puts connection on queue, broadcasts to
conn threads, releases lock

- every conn thread waiting on the condition is woken up in some
arbitrary but approximately round-robin order, and maybe some of the
conn threads which aren't currently waiting pick up that message when
they do wait, because for performance these things aren't strictly
guaranteed (I may be remembering this wrong)

- n conn threads race to acquire the lock

- the one which gets the lock first take the conn from the queue and
release the lock

- it runs the connection, acquires the lock again, puts the conn back
on the queue, and release the lock

- meanwhile the other woken conn threads acquire then release the lock
with possibly nothing to do.


So for each request there can be up to 6 lock/unlock sequences by the
driver and active conn thread, plus a lock/unlock by n other conn
threads, all on one contended lock, plus the context switching
overhead, and this all happens in an undesirable order.


> By having a conn-thread-queue, the
> threads have to update this queue with their status
> information (being created, warming up, free, busy,
> will-die) which requires some overhead and more mutex locks
> on the driver.


I was thinking it could work something like this:


- driver acquires lock, takes first conn thread off queue, releases lock

- driver thread puts new socket in conn structure and the signals on
cond to that one thread (no locking, I don't think)

- that conn thread wakes up, takes no locks, runs connection

- conn thread acquires driver lock, puts conn back on front of queue,
releases lock


Four lock/unlock, lock/unlock sequences, two threads.

------------------------------------------------------------------------------
WINDOWS 8 is here. 
Millions of people.  Your app in 30 days.
Visit The Windows 8 Center at Sourceforge for all your go to resources.
http://windows8center.sourceforge.net/
join-generation-app-and-make-money-coding-fast/
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel

Reply via email to