On Wednesday, October 16, 2002, at 05:49 AM, Jim Starkey wrote:

> At 02:42 PM 10/15/02 -0700, John Bellardo wrote:
>> [...]
>>>
>>> The engine currently uses the page locks issued by the cache
>>> manager to synchronize access to pages within a process knowing
>>> that a thread switch can't happen while a page is in use.
>>
>> I'm not 100% sure. But I am sure that no matter what direction we
>> choose there will be some very tricky parts of the code that need to
>> be
>> modified. Here are two different approaches I can think of off the
>> top
>> of my head:
>>
>> 1. two level locks - Each process is responsible for allocating its
>> own locks internally to threads. But it must maintain an externally
>> visible (to other processes) lock with sufficient rights to cover all
>> of its inner-process locks.
>>
>
> This is probably the way to go. The semantic of page locks and
> internal resource locks are quite different. External locks
> require blocking ASTs and deadlock detection. Internal locks
> are presumed deadlock free. The idea of siezing the lock table
> semaphore for each synchronized thread resource.
>
> Which brings to mind another problem. Lock grants and blocks
> are communicated in classic by signals. Pthread semantics
> require that signals be delivered to all threads.
> And, if
> I remember correctly, none of the pthread synchronization
> primitives are safe for use in signals.

And if that weren't enough not all platforms support full pthread
signaling semantics. Which means that we can't mix threads and signals.

> Any good ideas of
> how to handle this problem?

I'm not sure if it is a "good" solution, but with signals ruled out
that leaves semaphores and messages. Of the two semaphores just won't
hack it, which leaves messages. So, we could have a single thread
waiting to receive messages. We would need to use some form of named
message queues which means we probably want each process to put it's
message queue name in the owner section (is that the right
terminology?) of the lock table.

In the degenerate case each process would have n-1 (where n is the
total number of server processes) file descriptors opened to the other
processes just for the purpose of messaging. If this seems like too
much we may have to consider a separate lock manager process.

>
> [...more examples of bad thread/signal interactions snipped...]

-John